Re: 3.0.4 core dump

matthew mcglynn wrote: > > I've moved this thread to the dev list because I think > it's of limited appeal. I have not reported a bug yet because > I believe I have not collected quality data on the crash. > > Me: > > > >This time I built PHP with debugging, so I'm hoping this > > >core file will be of some use to someone. > > Zeev: > > > It might be if you make use of it :) You should generate a gdb backtrace > > and send it to us at php-dev@php.iquest.net, or better yet, submit a bug > > report on http://ca.php.net/bugs.php3. > > > > To generate a backtrace, run > > gdb /path/to/php/cgi /path/to/corefile > > and at the gdb prompt type > > (gdb) bt > > I'm happy to do this but unfortunately something is amiss. I > think I stripped the binary before I installed it. This would > make a backtrace sort of useless, wouldn't it ? How is > stripping related to compiling with debug symbols (if at all) ? > > My do-conf for this binary: > ./configure > --with-gd=no > --with-mysql=/usr/local/mysql > --with-config-file-path=/usr/local/apache/etc > --enable-track-vars=yes > > The lack of "--enable-debug=no" would indicate that the > binary was built with debugging, right ? gdb complains > of no debugging symbols, which is due to the fact that I > stripped the binary I guess. > > Even so, I rebuilt the binary and ran it (unstripped) > against this core file and it generated the following > trace -- which I realize may be bogus because the binary > has changed. For now it's all I've got -- if it core dumps > again tonight I'll have better info. > > warning: exec file is newer than core file. > Core was generated by `cardbot.php3'. > Program terminated with signal 11, Segmentation fault. > #0 0x209ab in _php3_hash_find (ht=0xa7fa4, arKey=0x0, nKeyLength=18, pData=0xefbfd000) at > php3_hash.c:834 > 834 HANDLE_NUMERIC(arKey, nKeyLength, _php3_hash_index_find(ht,idx,pData)); > (gdb) bt > #0 0x209ab in _php3_hash_find (ht=0xa7fa4, arKey=0x0, nKeyLength=18, pData=0xefbfd000) at > php3_hash.c:834 > #1 0xe1ea in phpparse () at control_structures_inline.h:848 > #2 0x1f01a in php3_parse (yyin=0xa5d24) at main.c:1461 > #3 0x1faa5 in main (argc=3, argv=0xefbfdefc) at main.c:1769 > > That's all it gives me. I haven't used gdb in 6 years so > if there's more I can do, please let me know. > > > What kind of script is it? Can you run it and see if it crashes on every > > run? About the -lpthread issue, it's unclear whether it should affect the > > CGI or not. It will clearly be removed completely in 3.0.5. > > The script performs a variety of database admin tasks. This > is the nightly batch script for a large "digital postcard" > website, so this script is searching for unsent cards (in > a MySQL table) and generating lots of emails. > > It does not crash on every run -- I ran it 5 minutes after > it core dumped and it completed the task. Of course, the first > (partial) run had changed the db, so the second run was not > duplicating any effort, or even necessarily running the same > code, depending on where it died the first time. > > -- > matt. Ok, it's certainly not the bug I fixed, it would have happened we module shutdown, not php3_parse. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net