Age | Commit message (Collapse) | Author | Files | Lines |
|
(closes issue #18481)
Reported by: pabelanger
Patches:
20101215__issue18481.diff.txt uploaded by tilghman (license 14)
Tested by: pabelanger
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@298392 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
database.
(closes issue #16940)
Reported by: jamicque
Patches:
20100827__issue16940.diff.txt uploaded by tilghman (license 14)
20100921__issue16940__1.6.2.diff.txt uploaded by tilghman (license 14)
Tested by: jamicque
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@288265 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Since we are just checking for table existence, add a WHERE clause that will
return no rows but will raise an error if the table doesn't exist.
(closes issue #17380)
Reported by: kkwong
Patches:
issue17380-01.patch uploaded by seanbright (license 71)
Tested by: kkwong
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@269006 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I came across this while doing some testing of my ast_channel_ao2 branch.
After running a test overnight that generated over 5 million calls, Asterisk
had taken up about 1 GB of my system memory. So, I re-ran the test with
MALLOC_DEBUG turned on. However, it showed no leaks in Asterisk during the
test, even though Asterisk was still consuming it somehow.
Instead, I turned to valgrind, which when run with --leak-check=full, told
me exactly where the leak came from, which was from allocations inside the
radiusclient-ng library. This explains why MALLOC_DEBUG did not report it.
After a bit of analysis, I found that we were leaking a little bit of memory
every time a CDR record was passed to cdr_radius.
I don't actually have a radius server set up to receive CDR records. However,
I always have my development systems compile and install all modules. In
addition to making sure there are not build errors across modules, always
loading modules helps find bugs like this, too, so it is strongly recommend for
all developers.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@186229 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ABE-1628 and RYM-150398 and AST-103 in internal Digium
bug trackers.
These fixes address a really subtle memory corruption
problem that would happen in machines heavily loaded
in production environments. The corruption would
always take the form of the STMT object getting
nulled out and one of the unixODBC calls would
crash trying to access statement->connection.
It isn't fully proven yet, but the server has
now been running 2.5 days without appreciable
memory growth, or any gain of %cpu, and no
crashes. Whether this is the problem or not
on that server, these fixes are still warranted.
As it turns out, **I** introduced these errors
unwittingly, when I corrected another crash earlier.
I had formed the build_query routine, and failed
to remove mutex_unlock calls in 3 places in the
transplanted code. These unlocks would only
happen in error situations, but unlocking the
mutex early set the code up for a catastrophic
failure, it appears. It would happen only once
every 100K-200K or more calls, under heavy load...
but that is enough.
If another crash occurs, with the same MO,
I'll come back and remove my confession from the log, and
we'll keep searching, but the fact that we
have Asterisk dying from an asynchronous
wiping of the STMT object, only on some connection
error, and that the server has lived for 2.5
days on this code without a crash, sure make
it look like this was the problem!
Also, in several points, Statement handles are
set to NULL after SQLFreeHandle. This was mainly
for insurance, to guarantee a crash. As it turns
out, the code does not appear to be attempting
to use these freed pointers.
Asterisk owes a debt of gratitude to Federico Alves
and Frediano Ziglio for their untiring efforts in
finding this bug, among others.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@150056 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
was not getting set in the STMT; it was coming out,
usually, as binary garbage to an mssql server.
These changes fixed the problem. The only thing
I can venture forth as a guess, is that the pointer
is being stored in the interface, not a copy of the
string. Because we ripped the build process into a
subroutine, the timestr became a temp. stack variable,
and between the time the STMT got built and the
time it was executed on the server, the string being
pointed to was damaged. At any rate, even if this
theory is false, and some mechanism was at fault,
this fix worked reliably where it didn't before.
Why this bug didn't bite last week, I have no idea.
This change basically defines the timestr buffer
in the calling function, extending the life of the
buffer to cover both the STMT's building and
processing to the server.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@143964 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
hung channels when the mssqlserver bounces. All the connections then become invalid, and must be reconnected. The cdr_odbc backend had code to do it, but depended on re-establishing the connection, but re-using the STMT that had been built. By trial and error, we determined that the STMT could not be re-used after the connection was re-established. and must be rebuilt. These changes accomplish this.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@143674 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
CDR(userfield) if it is set. The new behavior is to check for the userfield
column on module load, and if it exists, we will store CDR(userfield) when
CDRs are written. A similar patch already went into trunk and 1.6.0.
(closes issue #13290)
Reported by: falves11
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137348 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
this tree is not yet ready for users to be easily upgrading or switching, but it needs to be :-)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130298 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
is needed to correct the problem. Track whether the load succeeded with a
variable, so we can fix this with a simple reload event, instead.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@113874 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Fixes issue #12268.
Patch borrowed from r82344
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@110779 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@93183 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@93180 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Fixes AST-2007-026)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90166 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
leakage I've already fixed, but it doesn't hurt to double check. I found and fixed leaks in res_jabber, cdr_tds, pbx_ael. Nothing major, tho.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89088 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the same file.
Do we actually need the locking here? What happens if you open the same file twice, and
two threads try to write to it at the same time? Is fputs() going to write out the entire
line at once? I suspect that it could be possible for the second fopen to run during the
first fputs, so the position could be in the middle of the previously written line...
Issue 10347, initial patch by explidous (but I removed all of the paranoia stuff..)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82344 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@78146 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: prashant_jois
Patches:
cdr_pgsql.patch uploaded by prashant (license 114)
Finish the Postgresql connection after the log messages are printed so we don't access invalid memory.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@77540 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the same variable twice.
This patch sets the connection to NULL after calls to PQfinish so that the problem does not occur.
Also in this patch, prashant_jois informed me that it is safe to pass a null pointer to PQfinish, so
I have removed the check for conn's existence from my_unload_module.
(closes issue 10295, reported by junky, patched by me with input from prashant_jois)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@77318 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r70804 | murf | 2007-06-21 13:13:17 -0600 (Thu, 21 Jun 2007) | 1 line
it was pointed out that the cdr_custom config load could get a lock, and under certain circumstances, would never release it. I also noted that the situation where more than one mapping spec was warned about, but did not ignore further mappings as it had promised. I think I have fixed both situations.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70841 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Issue 10020, patch by my, with credit to prashant_jois for pointing out the problem.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70612 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70560 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Issue 10022, patch by me, with credit to prashant_jois for finding the bug.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70554 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
still can't build *_odbc.so!", check for ltdl directly, instead of just listing
it as another library to include in the unixodbc check in the configure script.
This also makes ltdl show up as a dependency in menuselect so people know what
to go install. (related to issue #9989, patch by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@69702 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@69392 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
not called on the result structure after doing a PQexec(). Also, fix up some
formatting in passing.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@69016 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
channel_alloc func, set the cid_num and name fields from the arglist[blush]. c) don't update the channel app & app data fields if you are in the 'h' extension. d)the load_module func in cdr_radius needs to return DECLINE, SUCCESS.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@62689 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r59301 | tilghman | 2007-03-29 11:04:46 -0500 (Thu, 29 Mar 2007) | 3 lines
Issue 9415 - No point to getting a diagnostic field if we aren't doing anything with the information.
(Plus, it tends to crash the Postgres ODBC driver.)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@59302 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
file existed.
Issue 8777
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@50346 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r47583 | file | 2006-11-13 16:26:36 -0500 (Mon, 13 Nov 2006) | 2 lines
Initialize global pointers for connection and result to NULL. (issue #8356 reported by james)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@47584 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ast_copy_string instead of strncpy... fix up many more users, and fix some bugs in the process
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@46200 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r45927 | file | 2006-10-22 20:25:28 -0400 (Sun, 22 Oct 2006) | 2 lines
Don't leak memory mmmk?
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@45928 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43409 | tilghman | 2006-09-21 11:18:19 -0500 (Thu, 21 Sep 2006) | 2 lines
TDS 0.64 updates
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@43410 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43373 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43370 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43369 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(issue 7983).
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43364 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41651 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
now reports AST_MODULE_LOAD_DECLINE when loading if config file
is not there, also fixed an error in res_config_pgsql where it
had a non static function when it should.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41633 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
directives
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41209 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@40722 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
don't reuse LIBS variable from top-level Makefile (oops)
build Asterisk binary after subdirs (preparing for embedded modules)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@37661 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@37222 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@37085 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@36255 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@35895 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
minute train ride from Paris to London <G>)
support the new location for zaptel.h and tonezone.h
use the dependency information output by menuselect to build Makefile rules for each module for header files and libraries
combine the common rules into a top-level Makefile.rules file
remove all (now) unnecessary stuff from subdir Makefiles
change translator API so that the newpvt() callback returns an int instead of a pointer (it no longer allocates memory)
alphabetize --with-<foo> options in configure script
enhance Net-SNMP support in configure script to provide a --with-netsnmp option
fix support for --with-pq so that if pg-config is not found when --with-pq is specified, an error will be generated
add 'optional package' usage to modules now that menuselect can output it
allow res_snmp to build by default, since the new loader changes coming soon will solve the function naming problem (and users can disable it via menuselect anyway)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@35832 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
subdirectory instead of a for loop
- remove the FORCE target from the main Makefile and add the couple places
I used it to the .PHONY target. .PHONY does the same thing and is a built-in
more efficient way of doing it.
- add a bunch more targets to .PHONY ...
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@35503 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- use separate targets instead of a for loop for doing 'make depend' for
each sub directory
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@35501 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- add a copyright header to the build_tools Makefile
- remove 'depend' from the 'all' target in agi/ and utils/ since it is handled
by the main Makefile already
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@35479 f38db490-d61c-443f-a65b-d21fe96a405b
|