php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #17402 pspell_new causes a segmentation fault (11)
Submitted: 2002-05-24 03:14 UTC Modified: 2002-09-15 16:21 UTC
Votes:189
Avg. Score:4.9 ± 0.3
Reproduced:185 of 188 (98.4%)
Same Version:26 (14.1%)
Same OS:137 (74.1%)
From: brett at i-com dot co dot nz Assigned:
Status: Closed Package: Pspell related
PHP Version: 4.2.1 OS: Mandrake 8.2
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: brett at i-com dot co dot nz
New email:
PHP Version: OS:

 

 [2002-05-24 03:14 UTC] brett at i-com dot co dot nz
My browser reports that the page cannot be displayed,
and the apache log includes a segmentation fault (11),
when I try and open the following php script.
When the pspell line is commented out the page displays:

"Hello".

Any suggestions? Thanks.

versions:
aspell 33.7.1
pspell 12.2 with patch
php 4.2.1
apache 1.3.24

php configure:

./configure \
  --with-debug \
  --with-mysql=/usr \
  --with-apxs=/usr/local/apache/bin/apxs \
  --with-pspell \
  --with-jpeg-dir=/usr/lib \
  --with-png-dir=/usr/lib \
  --with-zlib-dir=/usr/lib \
  --with-freetype-dir=/usr/lib \
  --with-gd=/usr \
  --enable-inline-optimisation

php script:

<?php
echo "<html>";
echo "Hello";
$dic = pspell_new("en");
echo "</html>";
?>

gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x003c2c82 in throw_helper (eh=0x1010100, pc=0x0, my_udata=0x0,
    offset_p=0xbfffdaa0) at ../../gcc/libgcc2.c:3168
3168    ../../gcc/libgcc2.c: No such file or directory.
        in ../../gcc/libgcc2.c
(gdb) bt
#0  0x003c2c82 in throw_helper (eh=0x1010100, pc=0x0, my_udata=0x0,
    offset_p=0xbfffdaa0) at ../../gcc/libgcc2.c:3168
#1  0x0063b796 in aspell::Config::read_in (this=0x8, override=0x10)
    at /usr/include/g++-3/std/bastring.h:343
#2  0x0043c26c in __EXCEPTION_TABLE__ () from /usr/local/lib/libpspell.so.4
#3  0x003e37a1 in nothrow () from /usr/local/apache/libexec/libphp4.so
#4  0x00438a00 in PspellString virtual table ()
   from /usr/local/lib/libpspell.so.4

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-07 01:21 UTC] matt at iws dot co dot nz
This script will result in a segmentation fault:

<?php
$spell = pspell_new ("en");
?>

OS: Redhat 7.1 (2.4.2-2 Kernel)

php configure:

./configure \
 --with-mysql \
 --with-pgsql \
 --with-apxs=/usr/local/apache/bin/apxs \
 --enable-sockets \
 --with-gd \
 --with-jpeg-dir=/usr/lib \
 --with-png-dir=/usr/lib \
 --with-freetype-dir=/usr/local/lib \
 --with-zlib-dir=/usr/lib \
 --with-pdflib \
 --with-pspell


versions:
aspell 33.7.1
pspell 12.2 patched
apache 1.3.22
php 4.2.1

gdb backtrace:


Program received signal SIGSEGV, Segmentation fault.
0x4000da48 in _dl_signal_error () at eval.c:41
41      eval.c: No such file or directory.
        in eval.c
(gdb) backtrace
#0  0x4000da48 in _dl_signal_error () at eval.c:41
#1  0x401e1691 in _dl_close () at dl-close.c:61
#2  0x401e1330 in _dl_close (_map=0x81137a0) at dl-close.c:271
#3  0x400cc62a in dlclose_doit (handle=0x81137a0) at dlclose.c:25
#4  0x4000dc83 in _dl_catch_error () at eval.c:41
#5  0x400cc94b in _dlerror_run (operate=0x400cc610 <dlclose_doit>, args=0x81137a0) at dlerror.c:130
#6  0x400cc5f4 in dlclose (handle=0x81137a0) at dlclose.c:31
#7  0x40504f7e in sys_dl_close () from /usr/lib/libltdl.so.0
#8  0x40506784 in lt_dlclose () from /usr/lib/libltdl.so.0
#9  0x4037b380 in free_lt_handle (h=0x81136e8) at manager_impl.cc:29
#10 0x4037d58a in delete_pspell_manager (m=0x8111d88) at manager_impl.cc:303
#11 0x402a3cde in php_pspell_close (rsrc=0x811644c) at pspell.c:87
#12 0x40254279 in list_entry_destructor (ptr=0x811644c) at zend_list.c:177
#13 0x40253044 in zend_hash_apply_deleter (ht=0x4035cb3c, p=0x8111e44) at zend_hash.c:596
#14 0x40253196 in zend_hash_graceful_reverse_destroy (ht=0x4035cb3c) at zend_hash.c:662
#15 0x402543c8 in zend_destroy_rsrc_list (ht=0x4035cb3c) at zend_list.c:233
#16 0x40246202 in shutdown_executor () at zend_execute_API.c:196
#17 0x4024e8d6 in zend_deactivate () at zend.c:596
#18 0x4025ada8 in php_request_shutdown (dummy=0x0) at main.c:787
#19 0x40257eec in apache_php_module_main (r=0x810acc4, display_source_mode=0) at sapi_apache.c:96
#20 0x4025896e in send_php (r=0x810acc4, display_source_mode=0, filename=0x0) at mod_php4.c:575
#21 0x402589c2 in send_parsed_php (r=0x810acc4) at mod_php4.c:590
#22 0x08072787 in ap_invoke_handler () at eval.c:41
#23 0x080869cf in process_request_internal () at eval.c:41
#24 0x08086a30 in ap_process_request () at eval.c:41
#25 0x0807de3d in child_main () at eval.c:41
#26 0x0807dfe8 in make_child () at eval.c:41
#27 0x0807e15c in startup_children () at eval.c:41
#28 0x0807e7d8 in standalone_main () at eval.c:41
#29 0x0807f037 in main () at eval.c:41
#30 0x400eb177 in __libc_start_main (main=0x807ec98 <main>, argc=2, ubp_av=0xbffffb5c, init=0x804e730 <_init>, 
    fini=0x809c090 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffffb4c) at ../sysdeps/generic/libc-start.c:129
 [2002-07-18 05:32 UTC] haireljay at voila dot fr
Same problem with PHP 4.2.1 AND 4.2.0

(Mandrake 8.2
aspell-0.33.7.1-3mdk.i586.rpm 
pspell-0.12.2-4mdk.i586.rpm
libpspell4-0.12.2-4mdk.i586.rpm
libpspell4-devel-0.12.2-4mdk.i586.rpm
libaspell10-0.33.7.1-3mdk.i586.rpm
libaspell10-devel-0.33.7.1-3mdk.i586.rpm)
 [2002-08-23 16:28 UTC] zummi at softhome dot net
this may be similar to bug 8133 and 8464
Still don't have a solution but it might be.
 [2002-09-07 01:21 UTC] vlad@php.net
matt@iws.co.nz - thanks for the backtrace. From what I can tell, this seems a bug in glibc 2.2.1 or a bit later triggered when a shared module can't be loaded, so the destructor is called and the destructor uses a buggy function to unload the pspell module. As zummi@softhome.net pointed out, it may be similar to bug 8133, so follow suggestions in that bug description.

Fixes:
1. Update your glibc. This will result in a normal error message being displayed about not being able to load a library, not a segfault.
2. Make sure libraries and dictionaries can be loaded (e.g. check permissions, your LD_LIBRARY_PATH, etc. so this condition never happens and the buggy code doesn't get to run.)

I am pretty sure this should fix the problem. Please, tell me if that works.
 [2002-09-15 15:45 UTC] matt at iws dot co dot nz
Thanks vlad@php.net updating glibc did solve the problem.
 [2002-09-15 16:21 UTC] derick@php.net
Closing then
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Tue Jul 01 20:01:36 2025 UTC