<div>Benedikt,</div>

<div>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.

</div>

<div> </div>

<div>I sincerely hope you will succeed, good luck!</div>

<div> </div>

<div>Best regards,</div>

<div>Umberto<br><br> </div>

<div><span class="gmail_quote">On 11/2/05, <b class="gmail_sendername">Benedikt Rothe</b> <<a href="mailto:umn-ms@hydrotec.de">umn-ms@hydrotec.de</a>> wrote:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br><font face="sans-serif" size="2">Thanks Umberto! Good hint. In this context I found something.</font> 

<br><br><font face="sans-serif" size="2">Since this kind of problem may occure to others to, I'll briefly </font><br><font face="sans-serif" size="2">summarize the steps I go:</font> <br><br><font face="sans-serif" size="2">

a) In map.h include somewhere the line</font> <br><font face="sans-serif" size="2">#include <mcheck.h></font> <br><br><font face="sans-serif" size="2">b) Compile Mapserver with debug-option:</font> <br><font face="sans-serif" size="2">

./configure <flags>  --enable-debug</font> <br><font face="sans-serif" size="2">make</font> <br><br><font face="sans-serif" size="2">c) Before starting tomcat set the environmentvariable  MALLOC_TRACE</font> <br><font face="sans-serif" size="2">

to the name of a logfile.</font> <br><font face="sans-serif" size="2">export MALLOC_TRACE=/opt/jakarta-tomcat-4.1.31/logs/malloctrace</font> <br><br><font face="sans-serif" size="2">The tracefile will contains information about calls to "malloc" and "free":

</font> <br><font face="sans-serif" size="2">   - Function called malloc/free </font><br><font face="sans-serif" size="2">   - address of allocated/freed memory</font> <br><br><font face="sans-serif" size="2">By this file one can look for the "pairs". 

</font><br><br><font face="sans-serif" size="2">I'll still have to test in in practice. But I'm hopefull, that this will help to </font><br><font face="sans-serif" size="2">narrow the problem down.</font> <br><br><font face="sans-serif" size="2">

Benedikt Rothe</font> <br><br><br><font size="2"><tt>Umberto Nicoletti <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:umberto.nicoletti@gmail.com" target="_blank">umberto.nicoletti@gmail.com</a>

> schrieb am 02.11.2005 12:29:05: 

<div><span class="e" id="q_107518eac6c72443_1"><br><br>> Newer glibc have internal checks that are probably turned on by<br>> default on some distros.<br>> Try to play with the MALLOC_CHECK_ variable and read this (it is about

<br>> fedora core, but should apply to suse too):<br>> <br>>     glibc<br>>       The version of glibc provided with Fedora Core 3 performs<br>>       additional internal sanity checks to prevent and detect data

<br>>       corruption as early as possible. By default, should corruption<br>>       be detected, a message similar to the following will be displayed<br>>       on standard error (or logged via syslog if stderr is not open):

<br>> <br>>       *** glibc detected *** double free or corruption: 0x0937d008 ***<br>> <br>>       By default, the program that generated this error will also be<br>>       killed; however, this (and whether or not an error message is

<br>>       generated) can be controlled via the MALLOC_CHECK_ environment<br>>       variable. The following settings are supported:<br>> <br>>             0 -- Do not generate an error message, and do not kill the program

<br>>             1 -- Generate an error message, but do not kill the program<br>>             2 -- Do not generate an error message, but kill the program<br>>             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.

<br>> <br>>       Should you have a program from a third party ISV that triggers<br>>       these corruption checks and displays a message, you should<br>>       file a defect report with the application's vendor, since this

<br>>       indicates a serious bug.<br>> <br>> Best regards,<br>> Umberto<br>> <br>> On 11/2/05, Benedikt Rothe <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:umn-ms@hydrotec.de" target="_blank">

umn-ms@hydrotec.de</a>> wrote:<br>> ><br>> > Dear Mapserver-Users<br>> ><br>> > We developed a Tomcat/Mapserver-Site using Mapscript on<br>> > Linux/SUSE 9.3.<br>> ><br>> > Many things run fine. On a test-machine we made successfully

<br>> > some stress-testing and Tomcat runs for weeks.<br>> ><br>> > Unfortunately Tomcat crashes on the customers production-machine<br>> > approximately once a day. It runs for several hours,<br>

> > passes stress-tests successfully but crashes unpredictable after<br>> > 12-20hours.<br>> ><br>> > The crash occurs in Mapserver-Code. Message in the Tomcat-log<br>> > is<br>> > *** glibc detected *** double free or corruption (top): 0x0xf99950"

<br>> ><br>> > Question: Can I do something to make this error-message more helpful?<br>> > I'd like to have the stack and the line-numbers in the sourcecode.<br>> > (I mean the C-stack and C-linenumber and not the Java-Stack...)

<br>> ><br>> > I looked through the gcc-man-page, but I coudn't find anything helpful.<br>> ><br>> > Thanks<br>> > Benedikt Rothe<br></span></div></tt></font></blockquote></div><br>