When moving the cursor backward and pressing TAB to autocomplete, a NULL is put
in the line and we are loosing what we have already wrote after the actual
cursor position.
(closes issue #14373)
Reported by: eliel
Patches:
asterisk.c.patch uploaded by eliel (license 64)
Tested by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184188 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@182810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk runs as a non-root user and the administrator does a 'restart now',
Asterisk loses the ability to set QOS on packets.
(closes issue #14004)
Reported by: nemo
Patches:
20090105__bug14004.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@172438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tzafrir
Replace a bunch of if defined checks for Zaptel/DAHDI through several new defines in dahdi_compat.h. This removes a lot of code duplication. Example from bug:
#ifdef HAVE_ZAPTEL
fd = open("/dev/zap/pseudo", O_RDWR);
#else
fd = open("/dev/dahdi/pseudo", O_RDWR);
#endif
is replaced with:
fd = open(DAHDI_FILE_PSEUDO, O_RDRW);
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@165991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pointer inside editline to look back to asterisk.c, so others don't spend
as much time as I did looking (in the wrong place) for the appropriate
function.
Reported by: ZX81, via the #asterisk-users channel
Fixed by: me (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@163761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is messed up. By intercepting those events with a signal handler in the remote
console, we can avoid those issues.
(closes issue #13464)
Reported by: tzafrir
Patches:
20081110__bug13464.diff.txt uploaded by Corydon76 (license 14)
Tested by: blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@163383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The test is not valid. Besides, if we actually suspected that recursive
mutexes were not working, we would get a ton of LOG_ERROR messages when
DEBUG_THREADS is turned on.
(inspired by a discussion on the asterisk-dev list)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@162413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
console option to be after the code that reads options from asterisk.conf.
This resolves a situation where Asterisk can start taking up 100% when
misconfigured.
(Thanks to Bryce Porter (x86 on IRC) for letting me log in to his system to
figure out what was causing the 100% CPU problem.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@156164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
deadlock when someone tries to initiate a module reload from the AMI just
as Asterisk is starting.
(closes issue #13778)
Reported by: hotsblanc
Fix suggested by hotsblanc
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@151905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A comment was made in bug #13726
"3. The same mistake as in (2) is done in a few other places in the code that check for: #if defined(HAVE_ZAPTEL) || defined(HAVE_DAHDI)
Harmless, but still incorrect."
In the case of main/asterisk.c, this is not incorrect because without HAVE_ZAPTEL defined, we're missing
the include for ioctl and the namespace that defines DAHDI_TIMERCONFIG which is still required when
using Zaptel with the 1.4 branch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@151167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Don't always define HAVE_ZAPTEL_CHANALARMS (since we check if it's defined..)
Minor cleanup to make things clear.
(closes issue #13726)
Reported by: tzafrir
Patches:
dahdi_def.diff uploaded by tzafrir (license 46)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_chanspy should be set at load time, not at compile
time, since dahdi_chan_name is determined at load time.
Also changed the next_unique_id_to_use to have the
static qualifier.
Also added the dahdi_chan_name_len variable so that
strlen(dahdi_chan_name) isn't necessary. Thanks to
seanbright for the suggestion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@133169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
correct registration of AMI actions in chan_dahdi; in zap-only mode, only register the Zap flavors of the actions (and use Zap prefixes for headers and acks), but in dahdi+zap mode, register both Zap and DAHDI flavors of actions
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These changes fix up some dubious code that I came across while auditing what
happens in the autoservice thread when there are no channels currently in
autoservice.
1) Change it so that autoservice thread doesn't keep looping around calling
ast_waitfor_n() on 0 channels twice a second. Instead, use a thread condition
so that the thread properly goes to sleep and does not wake up until a
channel is put into autoservice.
This actually fixes an interesting bug, as well. If the autoservice thread
is already running (almost always is the case), then when the thread goes
from having 0 channels to have 1 channel to autoservice, that channel would
have to wait for up to 1/2 of a second to have the first frame read from it.
2) Fix up the code in ast_waitfor_nandfds() for when it gets called with no
channels and no fds to poll() on, such as was the case with the previous code
for the autoservice thread. In this case, the code would call alloca(0), and
pass the result as the first argument to poll(). In this case, the 2nd
argument to poll() specified that there were no fds, so this invalid pointer
shouldn't actually get dereferenced, but, this code makes it explicit and
ensures the pointers are NULL unless we have valid data to put there.
(related to issue #12116)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@105563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Normally, we would not backport features into 1.4, but, I was convinced by the
justification supplied by the supplier of this patch. He pointed out that this
patch removes a requirement for running as root, thus reducing the potential
impacts of security issues.
(closes issue #11742)
Reported by: paravoid
Patches:
libcap.diff uploaded by paravoid (license 200)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and retrieve its output. The issue was that there was no way for the main Asterisk
process to know that the remote console was connecting in the -rx mode. The way that
James has fixed this is to have all remote consoles muted by default. Then, regular
remote consoles automatically execute a CLI command to unmute themselves when they
first start up.
(closes issue #10847)
Reported by: atis
Patches:
asterisk-consolemute.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
