<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
<br>> <br>> Note<br>> <br>> If MALLOC_CHECK_ is explicitly set a value other than 0, this<br>> causes glibc to perform more tests that are more extensive than<br>> 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>