aboutsummaryrefslogtreecommitdiffstats
path: root/cdr
AgeCommit message (Collapse)AuthorFilesLines
2009-04-03Fix a memory leak in cdr_radius.russell1-3/+9
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
2008-10-16This patch is relevant to:murf1-3/+12
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
2008-09-23In at least one machine, we noted that the timestrmurf1-8/+7
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
2008-09-19This fix comes from a debugging session on a test box that has been getting ↵murf1-10/+15
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
2008-08-13Bring cdr_tds in line with the other CDR backends and have it try to storeseanbright1-74/+175
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
2008-07-11a whole pile of Zaptel/DAHDI compatibility work, with lots more to come... ↵kpfleming1-1/+1
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
2008-04-09If the [csv] section does not exist in cdr.conf, then an unload/load sequencetilghman1-1/+11
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
2008-03-25Make file access in cdr_custom similar to cdr_csv.qwell1-9/+10
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
2007-12-17fix some copy-and-paste leftoverskpfleming1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@93183 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-17In http://lists.digium.com/pipermail/asterisk-dev/2007-December/031145.html,kpfleming1-2/+8
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
2007-11-29Properly escape cdr->src and cdr->dst and ensure we use thread-safe escapingtilghman1-11/+16
(Fixes AST-2007-026) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90166 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-07In response to 10578, I just ran 1.4 thru valgrind; some of the config ↵murf1-2/+4
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
2007-09-13Fix a crash that could occur in cdr_csv when mutliple threads tried to close ↵qwell1-10/+18
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
2007-08-05Portability fix for devmode compiling (closes bug #10382)tilghman1-1/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@78146 f38db490-d61c-443f-a65b-d21fe96a405b
2007-07-27(closes issue #10310)file1-2/+2
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
2007-07-26Two consecutive calls to PQfinish could occur, meaning free gets called on ↵mmichelson1-2/+3
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
2007-06-21Merged revisions 70804 via svnmerge from murf1-4/+6
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
2007-06-20Fix some potential memory leaks in cdr_pgsql.qwell1-1/+4
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
2007-06-20Fix a stupid mistake in my last cdr_pgsql race condition fixqwell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70560 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-20Fix a race condition in cdr_pgsql that can occur when reloading the module.qwell1-1/+5
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
2007-06-18To prevent 92138749238754 more reports of "I have unixodbc installed, butrussell1-0/+1
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
2007-06-14use ast_localtime() in every place localtime_r() was being usedkpfleming7-13/+13
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@69392 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-12Fix a memory leak pointed out by prashant_jois in #asterisk-bugs. PQclear() wasrussell1-6/+7
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
2007-05-02a)In chan_zap, set the clid, src fields in channel_alloc call. b)in the ↵murf1-3/+5
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
2007-03-29Merged revisions 59301 via svnmerge from tilghman1-4/+0
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
2007-01-10Reverse some logic in cdr_manager, which made it fail to load if the config ↵qwell1-1/+1
file existed. Issue 8777 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@50346 f38db490-d61c-443f-a65b-d21fe96a405b
2006-11-13Merged revisions 47583 via svnmerge from file1-2/+2
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
2006-10-25apparently developers are still not aware that they should be use ↵kpfleming1-2/+2
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
2006-10-23Merged revisions 45927 via svnmerge from file1-1/+2
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
2006-09-21Merged revisions 43409 via svnmerge from tilghman1-3/+7
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
2006-09-20One last forgotten constified filetilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43373 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-20resolve compiler warnings from constificationrussell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43370 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-20Magical eightball says warnings be gone.file1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43369 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-20Constify the result of a config retrieval function, to avoid mutilation ↵tilghman2-2/+2
(issue 7983). git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43364 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-31fix some breakage, MOG DID IT!!!russell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41651 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-31everything that loads a config that needs a config file to runmogorman7-13/+22
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
2006-08-26GNU make already knows how to quietly ignore non-existent files in 'include' ↵kpfleming1-4/+1
directives git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41209 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-21merge new_loader_completion branch, including (at least):kpfleming9-134/+69
- 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
2006-07-15more Makefile cleanup and consistency stuffkpfleming1-1/+4
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
2006-07-06move rules file to prepare for generic rules filekpfleming1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@37222 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-05update dependency information to match new names for dependencieskpfleming1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@37085 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-29move FreeTDS version check into configure scriptkpfleming1-12/+0
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@36255 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-25use new (separate) dependencies file from menuselectkpfleming1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@35895 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-24The Eurostar Commit! (it's amazing how much work you can get done on a 150 ↵kpfleming1-71/+3
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
2006-06-22- convert the 'uninstall' target to use separate targets to process eachrussell1-1/+1
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
2006-06-22- specify that 'depend' is a .PHONY targetrussell1-1/+1
- 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
2006-06-22- specify that 'all' is a .PHONY targetrussell1-1/+1
- 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
2006-06-22add the 'clean', 'clean-depend', and 'dist-clean' targets as .PHONY targetsrussell1-0/+2
since they are targets that do not have resulting files and are never listed as prerequisites to real targets. Using .PHONY in this manner improves make performance by never having to check for resulting files. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@35415 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-19don't blow up in the sub Makefiles if menuselect.makeopts is not present. Thisrussell1-1/+3
is valid in some cases, such as "make clean". git-svn-id: http://svn.digium.com/svn/asterisk/trunk@34738 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-16remove "depend" from the "all" targets in sub Makefiles. The main Makefilerussell1-1/+1
already calls "make depend" for each of the subdirectories git-svn-id: http://svn.digium.com/svn/asterisk/trunk@34497 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-24 20:30:09 +0000