[Home]

Summary:ASTERISK-10804: Addons build problems
Reporter:Igor Goncharovsky (igorg)Labels:
Date Opened:2007-11-19 03:52:31.000-0600Date Closed:2008-04-30 07:28:16
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Addons/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) crash_cdr_mysql.txt
( 1) malloc_debug.txt
( 2) mallocdebug.asterisk.v1.diff
( 3) mallocdebug.asterisk-addons.v1.diff
( 4) valgrind.txt
Description:Latest MySQL CDR crash on start, if add noload to modules.conf all is OK. Back trace attached.
Comments:By: Joshua C. Colp (jcolp) 2007-11-19 07:53:07.000-0600

I can confirm that it loads fine for me and such, so I have a simple question to ask.

Did you recompile asterisk-addons?
By: Igor Goncharovsky (igorg) 2007-11-19 21:44:15.000-0600

Ok, looks like I have compiled addons with latest trunk ib some bad way. Issue can be closed.
By: Igor Goncharovsky (igorg) 2007-11-21 23:38:16.000-0600

I have repeated it again.
Tooday I've upgraded to latest trunk:
1. run 'make' and 'make clean' in both folders
2. run 'svn update'
3. then run ./configure --enable-dev-mode
4. Select modules as needed, then compile asterisk and install
5. Compile and install addons

I think that this is right sequence, but I have crash on loading cdr_mysql. Commenting one line in utils.c prevent it from crash. I'll try to watch what happend with valgrind....


By: Igor Goncharovsky (igorg) 2007-11-26 23:26:04.000-0600

Ok, after some debuging I've get that it crash only when I have uncommented option 'sock' option in cdr_mysql.conf. I'll continue debug and prepare the patch for this.
By: Igor Goncharovsky (igorg) 2007-11-27 00:42:24.000-0600

I can now understand why this happen only with 'sock' option and here some results:
1) Crash caused by ast_verbose (line 1441 in utils.c) by output first value: (int)(*buf)->len

2) Calling ast_str_make_space make this warning:
WARNING: Realloc of unalloced memory at 0x834ebf8, in ast_str_make_space of /usr/src/voip/asterisk-trunk/asterisk-89621.orig/include/asterisk/strings.h, line 403

3) May be here some memory corruption when calling ast_str_make_space, because I have no problem with getting value (int)(*buf)->len before call of this function.

4) Also this can be reproduced on every parameter, with length more then 16 characters, when buffer firstly allocated need to be extended.


By: Igor Goncharovsky (igorg) 2007-11-27 22:52:45.000-0600

Also you need to enable MALLOC_DEBUG compiler flag to reproduce this
By: Tilghman Lesher (tilghman) 2007-12-03 18:11:05.000-0600

Please follow the instructions in doc/valgrind.txt
By: Igor Goncharovsky (igorg) 2007-12-03 22:34:36.000-0600

Two files uploaded, also I have one question, posted to *-dev
By: Igor Goncharovsky (igorg) 2007-12-26 09:57:30.000-0600

Ok, I've spent more time and get a root of this issue. This is because compiler flags, that set for main asterisk have no effect on asterisk-addons (fo ex. NO_OPTIMIZE, MALLOC_DEBUG). Then allocation in cdr_mysql do not call __ast_calloc from astmm.c, but realloc check if block allocated and failed...
By: Jason Parker (jparker) 2007-12-26 17:10:26.000-0600

So, if that's the case, then this should already be fixed in latest svn trunk, with the buildsum changes Kevin made.  It will no longer allow a module to load if the build options (CFLAGS, basically) are different.  It was done to avoid exactly this situation.

Can you update both asterisk and asterisk-addons, and give this another try?
By: Igor Goncharovsky (igorg) 2007-12-26 21:24:10.000-0600

I already use latest SVN versions. Modules from addons built and load without any warnings. Can you built and reproduce my issue?
By: Igor Goncharovsky (igorg) 2007-12-26 23:12:45.000-0600

qwell, I think Kevin's change make impossible to load modules build for xxxxxx revision by yyyyyy revision. Here situation were we build latest addons for latest asterisk, but we have different build environment. Addons can built with different optimizations, with different header inclusion.

I'll post my changes in 4 hours, but it incomplete and not a cure.
By: Jason Parker (jparker) 2008-01-11 14:00:49.000-0600

You never added a patch here. :)
By: Igor Goncharovsky (igorg) 2008-01-23 23:41:20.000-0600

Ok, I have no time to make it, sorry. While debug this issue I also discover some optimization problems in addons. The list of changes:
1. Included astmm.h in cdr_mysql
2. dev-mode stuff in *-addons  must be placed after inclusion of makeopts
3. Use compiler -g3 key only when DONT_OPTIMIZE

The issues remaining:
1. DONT_OPTIMIZE if set in main asterisk build take no effect when building asterisk-addons. Asterisk-addons always built optimized, what case problems with debugging addons.
3. Add inclusion of astmm.h in Makefile
2. I can not understand why ASTCFLAGS in addons passed double times to gcc:
gcc -o app_saycountpl.o -c app_saycountpl.c   -fPIC -Werror -Wunused -Wundef -Wdeclaration-after-statement  -O6 -fPIC -Werror -Wunused -Wundef -Wdeclaration-after-statement  -O6 -MMD -MT app_saycountpl.o -MF .app_saycountpl.o.d -MP

I have no idea how to correctly pass CFLAGS fom asterisk menuselect to asterisk-addons Makefile to have correct behavior of MALLOC_DEBUG and DONT_OPTIMIZE.
By: jmls (jmls) 2008-02-17 12:54:49.000-0600

qwell, any further comments ?
By: Tilghman Lesher (tilghman) 2008-04-18 17:18:19

I'm still not convinced that any of these changes are necessary.
By: Igor Goncharovsky (igorg) 2008-04-18 23:07:16

Have you reproduce this issue? If yes, they apply changes for app_addon_mysql.c and this patch will solve crash (MALLOC_DEBUG must be enabled in asterisk and socket param should have enough length).

Problem that compile flags that used in makefiles, not in soucse, are always have empty value and not used in fact. Two samples:
* DONT_OPTIMIZE, have no effect and addons built always not optimized, that cause BIG problems with debug issues
* MALLOC_DEBUG. If main asterisk built with MALLOC_DEBUG and addons not, that cause crash on every use this debug code from addons.

Seems this is too hard to describe problem, better make correct solution to fix this situation. Will be back with patch.
By: Tilghman Lesher (tilghman) 2008-04-29 21:29:36

No, I cannot reproduce the issue.
By: Digium Subversion (svnbot) 2008-04-29 23:41:15

Repository: asterisk-addons
Revision: 578

U   branches/1.4/Makefile.rules

------------------------------------------------------------------------
r578 | tilghman | 2008-04-29 23:41:12 -0500 (Tue, 29 Apr 2008) | 13 lines

Don't exclude system header files when doing dependency checks.  The reason for
this is fairly obvious -- the Asterisk header files (but only in -addons) are
part of the system header files at that point, so a changed buildopts.h is
considered a change in the system headers.  We WANT that change to be
considered a reason to rebuild everything in -addons, since the buildsum will
no longer match at runtime.

Note that if you're building -addons, you'll still need to do a 'make clean'
to get the old dependency files to go away this first time, but after that,
the dependency checks will take care of it for you.

(Closes issue ASTERISK-10804)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk-addons?view=rev&revision=578
By: Digium Subversion (svnbot) 2008-04-30 07:26:48

Repository: asterisk-addons
Revision: 579

_U  trunk/
U   trunk/Makefile.rules

------------------------------------------------------------------------
r579 | kpfleming | 2008-04-30 07:26:47 -0500 (Wed, 30 Apr 2008) | 21 lines

Merged revisions 578 via svnmerge from
https://origsvn.digium.com/svn/asterisk-addons/branches/1.4

........
r578 | tilghman | 2008-04-29 23:46:37 -0500 (Tue, 29 Apr 2008) | 13 lines

Don't exclude system header files when doing dependency checks.  The reason for
this is fairly obvious -- the Asterisk header files (but only in -addons) are
part of the system header files at that point, so a changed buildopts.h is
considered a change in the system headers.  We WANT that change to be
considered a reason to rebuild everything in -addons, since the buildsum will
no longer match at runtime.

Note that if you're building -addons, you'll still need to do a 'make clean'
to get the old dependency files to go away this first time, but after that,
the dependency checks will take care of it for you.

(Closes issue ASTERISK-10804)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk-addons?view=rev&revision=579
By: Digium Subversion (svnbot) 2008-04-30 07:28:16

Repository: asterisk-addons
Revision: 580

_U  branches/1.6.0/
U   branches/1.6.0/Makefile.rules

------------------------------------------------------------------------
r580 | kpfleming | 2008-04-30 07:28:15 -0500 (Wed, 30 Apr 2008) | 29 lines

Merged revisions 579 via svnmerge from
https://origsvn.digium.com/svn/asterisk-addons/trunk

................
r579 | kpfleming | 2008-04-30 07:32:23 -0500 (Wed, 30 Apr 2008) | 21 lines

Merged revisions 578 via svnmerge from
https://origsvn.digium.com/svn/asterisk-addons/branches/1.4

........
r578 | tilghman | 2008-04-29 23:46:37 -0500 (Tue, 29 Apr 2008) | 13 lines

Don't exclude system header files when doing dependency checks.  The reason for
this is fairly obvious -- the Asterisk header files (but only in -addons) are
part of the system header files at that point, so a changed buildopts.h is
considered a change in the system headers.  We WANT that change to be
considered a reason to rebuild everything in -addons, since the buildsum will
no longer match at runtime.

Note that if you're building -addons, you'll still need to do a 'make clean'
to get the old dependency files to go away this first time, but after that,
the dependency checks will take care of it for you.

(Closes issue ASTERISK-10804)

........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk-addons?view=rev&revision=580