php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #6410 Ibase_close causes segfault
Submitted: 2000-08-28 23:49 UTC Modified: 2000-12-07 11:34 UTC
From: nigel at aims dot com dot au Assigned:
Status: Closed Package: InterBase related
PHP Version: 4.0.1pl2 OS: Linux 2.2.14-6.0.1, FreeBSD 4.0
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
18 - 5 = ?
Subscribe to this entry?

 
 [2000-08-28 23:49 UTC] nigel at aims dot com dot au
When trying to close a connection using ibase_close() against an interbase 6 SuperServer database on Linux 2.2.14-6.0.1, and apache_1.3.12, compiled with ecgs-2.91.66, and on FreeBSD 4.0, compiled with gcc version 2.95.2 19991024 (release), apache crashes with a segfault on both platforms.

gdb backtrace shows the following:(on linux)

(gdb) run -X
Starting program: /usr/local/www/bin/httpd -X
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x401a7117 in memcpy (dstpp=0x0, srcpp=0x8205bfc, len=24)
    at ../sysdeps/generic/memcpy.c:55
55      ../sysdeps/generic/memcpy.c: No such file or directory.
(gdb) bt
#0  0x401a7117 in memcpy (dstpp=0x0, srcpp=0x8205bfc, len=24)
    at ../sysdeps/generic/memcpy.c:55
#1  0x4003e51e in gds__msg_lookup () from /usr/lib/libgds.so
#2  0x4003e183 in gds__msg_format () from /usr/lib/libgds.so
#3  0x4003de35 in gds__interprete () from /usr/lib/libgds.so
#4  0x4003886d in isc_interprete () from /usr/lib/libgds.so
#5  0x808cc37 in php_if_ibase_errmsg ()
#6  0x808ce12 in php_if_ibase_errmsg ()
#7  0x80e9c3a in list_entry_destructor ()
#8  0x80e8bde in zend_hash_del_key_or_index ()
#9  0x80e998f in zend_list_delete ()
#10 0x80e5767 in _zval_dtor ()
#11 0x80e0ada in _zval_ptr_dtor ()
#12 0x80e8c79 in zend_hash_destroy ()
#13 0x80e0946 in shutdown_executor ()
#14 0x80e60eb in zend_deactivate ()
#15 0x807dea4 in php_request_shutdown ()
#16 0x807c226 in sapi_apache_send_headers ()
#17 0x8110a5e in ap_run_cleanup ()
#18 0x810f28d in ap_clear_pool ()
#19 0x810f301 in ap_destroy_pool ()
#20 0x811ebad in ap_child_terminate ()
#21 0x811ecec in ap_child_terminate ()
---Type <return> to continue, or q <return> to quit---
#22 0x811ee49 in ap_child_terminate ()
#23 0x811f476 in ap_child_terminate ()
#24 0x811fc03 in main ()
#25 0x401601eb in __libc_start_main (main=0x811f8bc <main>, argc=2, 
    argv=0xbffffa14, init=0x80631b8 <_init>, fini=0x814d5ac <_fini>, 
    rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffa0c)
    at ../sysdeps/generic/libc-start.c:90
(gdb) 

Is it safe to run (as a workaround) the ibase system under php401sp2 without closing the ibase connection?
Does php4 clean up after itself well enough to use this method until it is fixed?

Would the mempcy.c program it says is missing be the cause, or just a by-product of an incorrect system call?

If anyone has any suggestions, I'm willing to give them a go.

Thanks in advance for your time.

Nigel




Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-11-01 12:44 UTC] sniper@php.net
reclassified. Please try a snapshot from snaps.php.net.
 [2000-12-07 11:34 UTC] sniper@php.net
Reopen, if this still happens when using latest snapshot
from http://snaps.php.net/

--Jani
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 20:01:45 2024 UTC