Debug-Hints with Tomcat

[Umberto Nicoletti]

Benedikt,
I also have tried valgrind, electricfence and other tools like memcheck and
other malloc checkers one year ago to detect a mysterious segfault in java
mapscript, but gave up because of all the output they were generating.
 I sincerely hope you will succeed, good luck!
 Best regards,
Umberto

 On 11/2/05, Benedikt Rothe <umn-ms at hydrotec.de> wrote:
>
>
> Thanks Umberto! Good hint. In this context I found something.
>
> Since this kind of problem may occure to others to, I'll briefly
> summarize the steps I go:
>
> a) In map.h include somewhere the line
> #include <mcheck.h>
>
> b) Compile Mapserver with debug-option:
> ./configure <flags> --enable-debug
> make
>
> c) Before starting tomcat set the environmentvariable MALLOC_TRACE
> to the name of a logfile.
> export MALLOC_TRACE=/opt/jakarta-tomcat-4.1.31/logs/malloctrace
>
> The tracefile will contains information about calls to "malloc" and
> "free":
> - Function called malloc/free
> - address of allocated/freed memory
>
> By this file one can look for the "pairs".
>
> I'll still have to test in in practice. But I'm hopefull, that this will
> help to
> narrow the problem down.
>
> Benedikt Rothe
>
>
> Umberto Nicoletti <umberto.nicoletti at gmail.com> schrieb am 02.11.200512:29:05:
>
> > Newer glibc have internal checks that are probably turned on by
> > default on some distros.
> > Try to play with the MALLOC_CHECK_ variable and read this (it is about
> > fedora core, but should apply to suse too):
> >
> > glibc
> > The version of glibc provided with Fedora Core 3 performs
> > additional internal sanity checks to prevent and detect data
> > corruption as early as possible. By default, should corruption
> > be detected, a message similar to the following will be displayed
> > on standard error (or logged via syslog if stderr is not open):
> >
> > *** glibc detected *** double free or corruption: 0x0937d008 ***
> >
> > By default, the program that generated this error will also be
> > killed; however, this (and whether or not an error message is
> > generated) can be controlled via the MALLOC_CHECK_ environment
> > variable. The following settings are supported:
> >
> > 0 -- Do not generate an error message, and do not kill the program
> > 1 -- Generate an error message, but do not kill the program
> > 2 -- Do not generate an error message, but kill the program
> > 3 -- Generate an error message and kill the program
> >
> > Note
> >
> > If MALLOC_CHECK_ is explicitly set a value other than 0, this
> > causes glibc to perform more tests that are more extensive than
> > the default, and may impact performance.
> >
> > Should you have a program from a third party ISV that triggers
> > these corruption checks and displays a message, you should
> > file a defect report with the application's vendor, since this
> > indicates a serious bug.
> >
> > Best regards,
> > Umberto
> >
> > On 11/2/05, Benedikt Rothe <umn-ms at hydrotec.de> wrote:
> > >
> > > Dear Mapserver-Users
> > >
> > > We developed a Tomcat/Mapserver-Site using Mapscript on
> > > Linux/SUSE 9.3.
> > >
> > > Many things run fine. On a test-machine we made successfully
> > > some stress-testing and Tomcat runs for weeks.
> > >
> > > Unfortunately Tomcat crashes on the customers production-machine
> > > approximately once a day. It runs for several hours,
> > > passes stress-tests successfully but crashes unpredictable after
> > > 12-20hours.
> > >
> > > The crash occurs in Mapserver-Code. Message in the Tomcat-log
> > > is
> > > *** glibc detected *** double free or corruption (top): 0x0xf99950"
> > >
> > > Question: Can I do something to make this error-message more helpful?
> > > I'd like to have the stack and the line-numbers in the sourcecode.
> > > (I mean the C-stack and C-linenumber and not the Java-Stack...)
> > >
> > > I looked through the gcc-man-page, but I coudn't find anything
> helpful.
> > >
> > > Thanks
> > > Benedikt Rothe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20051102/57de1475/attachment.htm>