Using Slackware 7.1 or 8.0 doesn't seem to matter. Program is written in C++ using GNU's g++ compiler. Same failure with OpenSSL-0.9.6a/b. Problem: The web app that I'm coding dies after a few calls to "malloc()" or C++'s new in the middle of the call. No error code is returned. I've took out the fork() routine in the app so now I have a single process app, and can see the "Segmentation Fault" error. I new this was the error but now I can use gdb with it. From the previous posted question to this problem "Odd run-time failure." Lutz said to try ElectricFence, which I found 2.0.5 and have tried twice to use it. I haven't been able to get it to work just yet, I think my code is still linking to the C librarie's malloc() instead of the efence.a, but either way I will need to do more conversions from "new" calls to "malloc()" calls elsewhere in my code so when I do get the efence.a to link I'm not missing any calls for dynamic memory to be tracked. Current Troubleshooting data: Working with GDB I've compiled the code with OpenSSL (assuming the default libraries are shared). Running the web app then under GDB produces the following message when SIGSEGV thrown - "warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x400fd3b8 in malloc () from /lib/libc.so.6" However, if I stick "-static" in the linker call of Makefile and then run GDB with web app, GDB produces - "Program received signal SIGSEGV, Segmentation fault. chunk_alloc (ar_ptr=0x8136540, nb=40) at malloc.c:2814 2814 malloc.c: No such file or directory. Current language: auto; currently c" I have also run mtrace() and the output shows many unallocated memory accesses, and many unfree()d addresses, but after further reading the mtrace() man I found this at http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_38.html : "This last point is also why it is no good idea to call muntrace before the program terminated. The libraries are informed about the termination of the program only after the program returns from main or calls exit and so cannot free the memory they use before this time. " I don't call muntrace() I just let it run through to the end, then after giving it some thought most of the output from mtrace wouldn't tell me a whole lot since I'm getting a Segmentation Fault, of course there would be missing free()s. But to confirm that my code compiled without OpenSSL works just fine I ran mtrace() with it compiled without OpenSSL. It came back with like 4 accesses of unallocated space and 3 missing free()s, all of which were associated with *.so files and are persistent outside the runtime of my web app. So if my hunch is correct OpenSSL is doing something with memory that my C++ code butts heads with. I will try to work out ElectricFence linking issue in the meantime. But for now does anyone have a suggestions? Am I correct in my understanding of the mtrace() and the output. Does anyone currently use OpenSSL and GNU's g++ compiler (yes I know g++ is another interface to gcc) on Linux? Thanks in advance. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
