php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19278 SIGABRT during Apache startup with latest pspell
Submitted: 2002-09-07 08:43 UTC Modified: 2002-09-18 08:43 UTC
From: ast at domdv dot de Assigned: vlad (profile)
Status: Closed Package: Pspell related
PHP Version: 4.2.3 OS: Linux 2.4
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 this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ast at domdv dot de
New email:
PHP Version: OS:

 

 [2002-09-07 08:43 UTC] ast at domdv dot de
php 4.2.3 configured with "--with-pspell=shared,/usr" and
linked against the latest pspell library (included now in
the combined aspell/pspell package and available as
ftp://ftp.gnu.org/gnu/aspell/aspell-0.50.1.tar.gz) causes
SIGABRT during apache (1.3.26) startup when
"extension=pspell.so" is given in php.ini. Compiler is gcc 3.2, binutils version is 2.13.

Trailing lines of "strace /usr/local/apache/bin/httpsd -X"

open("/usr/local/php/lib/php/extensions/no-debug-non-zts-20020429/zlib.so", O_RDONLY) = 0
read(0, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\36\0"..., 1024) = 1024
fstat64(0, {st_mode=S_IFREG|0755, st_size=32246, ...}) = 0
mmap2(NULL, 30064, PROT_READ|PROT_EXEC, MAP_PRIVATE, 0, 0) = 0x40bf8000
mprotect(0x40bff000, 1392, PROT_NONE)   = 0
mmap2(0x40bff000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 0, 0x6) = 0x40bff000
close(0)                                = 0
dup(2)                                  = 0
close(2)                                = 0
dup(1)                                  = -1 EBADF (Bad file descriptor)
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
getpid()                                = 1348
kill(1348, SIGABRT)                     = 0
--- SIGABRT (Aborted) ---
+++ killed by SIGABRT +++

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-07 08:55 UTC] derick@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
 [2002-09-07 09:44 UTC] ast at domdv dot de
In case of SIGABRT a stacktrace doesn't really help - but
on request here it is.

titanic:~ # gdb /usr/local/apache/bin/httpsd
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpsd -X
Reading key for server titanic.lan.domdv.de:443
Launching... /usr/local/apache/bin/gcache
pid=3817
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGABRT, Aborted.
0x40254e61 in __kill () at __kill:-1
-1      __kill: No such file or directory.
        in __kill
(gdb) bt
#0  0x40254e61 in __kill () at __kill:-1
#1  0x40254c76 in raise () from /lib/libc.so.6
(gdb) quit
The program is running.  Exit anyway? (y or n) y
titanic:~ #

What may help more here is some other output:

titanic:~ # ltrace /usr/local/apache/bin/httpsd -X

<snip>

malloc(24)                                        = 0x080cd2c8
malloc(11)                                        = 0x080cd2e8
malloc(21)                                        = 0x080cd2f8
malloc(24)                                        = 0x080cd318
malloc(5)                                         = 0x080cd338
malloc(21)                                        = 0x080cd348
malloc(24)                                        = 0x080cd368
malloc(9)                                         = 0x080cd388
malloc(21)                                        = 0x080cd398
malloc(24)                                        = 0x080cd3b8
malloc(9)                                         = 0x080cd3d8
malloc(25)                                        = 0x080cd3e8
__xstat(3, "/etc/cram-md5.pwd", 0xbffff46c)       = -1
memset(0x0812e984, '\000', 28)                    = 0x0812e984
memset(0x0812e9a4, '\000', 16)                    = 0x0812e9a4
memset(0x0812e9f4, '\000', 20)                    = 0x0812e9f4
dup(2, 0x4055e660, 0x08094d84, 0x4042f23e, 0x0808b540) = 0
close(2)                                          = 0
dup(1, 0x4055e660, 0x08094d84, 0x4042f23e, 0x0808b540) = -1
__assert_fail(0x0807e807, 0x0807df84, 1656, 0x0807e7e8, 0x0808b540 <unfinished .
..>
--- SIGABRT (Aborted) ---
+++ killed by SIGABRT +++

The above shows that an assertion in the pspell module
fails.
 [2002-09-09 14:48 UTC] kalowsky@php.net
From my understanding of this, it looks like this is in the pspell library, and not PHP.  Or is that not what you were trying to convay?
 [2002-09-09 16:34 UTC] ast at domdv dot de
Hmm,
I didn't check the library but at least the command line tool
included in the package is verified to work properly. As
I'm not familiar with the pspell library interface, could
it be that the new library expects some parameter different
than the old library (could still be a bug in new pspell)?
 [2002-09-10 20:09 UTC] vlad@php.net
a lot (including some API) has changed since aspell and pspell got merged into one project. I don't know yet if that's why things don't work for you, but I'll look into it in a few days (as the time allows).

Assigning to myself, unless someone else wants to pick it up.
 [2002-09-11 21:18 UTC] vlad@php.net
I just checked latest aspell with php4.2.3 in CGI mode, and it seems to work well. I don't have an apache installation handy that I can hose, so further testing will have to wait a couple of days, but my guess is that I won't be able to reproduce your problem easily.
 [2002-09-12 18:26 UTC] vlad@php.net
I can not reproduce this. I am using the same version of aspell as you do, the same version of PHP, same version of apache and even same gcc. BTW: What makes you think that it's aspell that's crashing? Or did I miss something in your stack trace?

Also, could you also compile it statically and see if that helps?
 [2002-09-13 10:03 UTC] ast at domdv dot de
Could it be that in the end this is a compiler (flags) and/or configuration problem? Below my compiler and build configuration. If I find the time I'll try to find out something more over the weekend.

cflags and cxxflags:

CXXFLAGS=-O3 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations -fschedule-insns2 -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fdelete-null-pointer-checks -falign-loops -falign-jumps -falign-functions -mcpu=pentiumpro -march=pentiumpro -mmmx -minline-all-stringops

CFLAGS=-O3 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations -fschedule-insns2 -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fdelete-null-pointer-checks -falign-loops -falign-jumps -falign-functions -mcpu=pentiumpro -march=pentiumpro -mmmx -minline-all-stringops

php-4.2.3 configuration:

./configure  --with-apxs=/usr/local/apache/bin/apxs --prefix=/usr/local/php --with-config-file-path=/usr/local/php/conf --disable-short-tags --enable-bcmath=shared --enable-calendar=shared --with-gdbm=/usr --with-db3=/usr/BerkeleyDB/3.1.17 --enable-dba=shared --enable-dbase=shared --with-dom=shared --enable-ftp=shared --with-gd=shared,/usr --with-ttf --with-gettext=shared --with-imap=shared,/usr/imap --with-mcrypt=shared,/usr --with-mhash=shared --with-msql=shared --with-mysql=shared,/usr/local/mysql --with-png-dir=/usr --with-freetype-dir=/usr --enable-shmop=shared --enable-sockets=shared --enable-sysvsem=shared --enable-sysvshm=shared --with-zlib=shared --with-curl=shared,/usr --enable-xml=shared --enable-memory-limit --with-tsrm-pthreads --enable-shared --with-gnu-ld --with-jpeg-dir=/usr --with-openssl=shared,/usr --enable-yp=shared --with-pspell=shared,/usr --with-gmp=shared,/usr --with-bz2=/usr --enable-gd-imgstrttf --enable-gd-native-ttf
--with-expat-dir=shared,/usr --enable-inline-optimization --with-dom-xslt=shared --with-dom-exslt=shared --with-cyrus=shared

aspell-0.50.1 configuration:

./configure --prefix=/usr --sysconfdir=/etc --with-gnu-ld
 [2002-09-13 13:15 UTC] vlad@php.net
it would be fantastic if you try to compile a few less modules too. Like
./configure --with-apxs=/usr/local/apache/bin/apxs --with-pspell=shared,/usr --enable-debug
(or something like that)

If still crashes, maybe even remove 'shared' from --with-pspell.

Also, the question I asked before still stands:
What makes you think that it's aspell that's crashing? 
 [2002-09-15 12:58 UTC] ast at domdv dot de
Right now it seems that php pspell is not the guilty party.
I disabled all functionality in pspell.c, linked without
libpspell.so and there's no assertion abort.
Furthermore the abort occurs if only
libaspell-common-0.50.1.so is linked to pspell.so (the all
functionality disabled version) - seems that the problem is in
the library initialization of this aspell library. I'll
investigate further.
 [2002-09-15 14:51 UTC] ast at domdv dot de
pspell definitely isn't the guilty party. The assertion
is triggered when libaspell-common-0.50.1.so is loaded.
The function triggering the assertion is InitSSLServer()
which is part of Apache-SSL. InitSSLServer causes the assertion on closed stdout. I'm closing this bug here
and continue it on the Apache-SSL list after further
analysis.
 [2002-09-18 08:43 UTC] ast at domdv dot de
FYI:
The problem was actually located in libaspell-common-0.50.1.so
which did close stdin/stdout/stderr during dlclose(). The
problem is already fixed by the aspell author, if you need the
fix please see:

http://mail.gnu.org/pipermail/aspell-user/2002-September/000057.html
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 05:01:30 2024 UTC