Bug 39803 - Informix onit crashes on startup in RH7.1
Summary: Informix onit crashes on startup in RH7.1
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libc
Version: 7.1
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-05-09 03:30 UTC by Peter Schwenke
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-05-09 03:30:54 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2001:121 0 normal SHIPPED_LIVE GNU C Library bugfix update 2001-10-04 04:00:00 UTC

Description Peter Schwenke 2001-05-09 03:30:50 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
A few people have been having trouble with Informix after upgrading
to RedHat 7.1.  IDS7.3 works. 9.2UC1 does not.  This is after a clean
install.  One user also had done an upgrade. 

The problem is that  oninit segmentation faults immediately on
startup.  There is a thread on your news server and on
comp.databases.informix.  

How reproducible:
Always

Steps to Reproduce:
1. Install RH7.1
2. Install Informix IDS9.2UC1
3. Run oninit
	

Actual Results:  Segmentation Fau;lt

Expected Results:  Should have run

Additional info:

Here is as much info as I can work out.


Starting program: /opt/informix/bin/oninit


Program received signal SIGSEGV, Segmentation fault.
0x4000cd16 in _dl_signal_error () at eval.c:41
41      eval.c: No such file or directory.
        in eval.c
(gdb) where
#0  0x4000cd16 in _dl_signal_error () at eval.c:41
#1  0x40191067 in _dl_sym () at dl-sym.c:68
#2  0x40053679 in dlsym_doit (a=0xbffff004) at dlsym.c:39
#3  0x4000cf29 in _dl_catch_error () at eval.c:41
#4  0x40053902 in _dlerror_run (operate=0x40053658 <dlsym_doit>,
    args=0xbffff004) at dlerror.c:130
#5  0x40053643 in dlsym (handle=0xffffffff, name=0x8678498 "write")
    at dlsym.c:51
#6  0x080e0c31 in JVP_init_native () at eval.c:41
#7  0x080cd7a1 in main () at eval.c:41
#8  0x4009fe5e in __libc_start_main (main=0x80cd790 <main>, argc=1,
    ubp_av=0xbffff93c, init=0x80cca04 <_init>, fini=0x8651ffc <_fini>,
    rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffff934)
    at ../sysdeps/generic/libc-start.c:129



Setting a break point for dlsym and stepping through I ended up with
this.   RTLD_NEXT is a flag to dlsym

from dlfcn.h



(gdb) s
dlsym_doit (a=0xbfffee94) at dlsym.c:39
39      dlsym.c: No such file or directory.
        in dlsym.cifdef __USE_GNU
/* If the first argument of `dlsym' or `dlvsym' is set to RTLD_NEXT
   the run-time address of the symbol called NAME in the next shared
   object is returned.  The "next" relation is defined by the order
   the shared objects were loaded.  */
# define RTLD_NEXT      ((void *) -1l)


I don't see it in the man page.

(gdb) s

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) bt full
#0  0x4000da48 in _dl_signal_error () at eval.c:41
        ap = (void **) 0x401abe80
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0xbfffed94 ""
        result = 1075494528
        result = 3221220756
#1  0x401991f1 in _dl_sym () from /lib/libc.so.6
No symbol table info available.
#2  0x400536a0 in dlsym_doit (a=0xbfffee94) at dlsym.c:39
        a = (void *) 0xbfffee94
#3  0x4000dc83 in _dl_catch_error () at eval.c:41
        ap = (void **) 0x400555a8
        digval = 0
        digval = 0
        digval = 0
        digval = 0
       p = 0x0
        result = 1074091432
        result = 0
#4  0x4005394b in _dlerror_run (operate=0x40053680 <dlsym_doit>, 
    args=0xbfffee94) at dlerror.c:130
        once = 1
        result = (struct dl_action_result *) 0x400555a8
#5  0x40053666 in dlsym (handle=0xffffffff, name=0x8678498 "write")
    at dlsym.c:51
---Type <return> to continue, or q <return> to quit---
        handle = (void *) 0x0
        name = 0x401abe80 "RTLD_NEXT used in code not dynamically loaded"
        args = {handle = 0xffffffff, name = 0x8678498 "write", 
  who = 0x80e0c31, sym = 0x0}
#6  0x080e0c31 in JVP_init_native () at eval.c:41
        ap = (void **) 0xbffff7cc
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x40016b64 ""
        result = 3221223372
        result = 1073834852
#7  0x080cd7a1 in main () at eval.c:41
        ap = (void **) 0xbffff7cc
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x40016b64 ""
        result = 3221223372
        result = 1073834852
#8  0x400a0237 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.

and with strace

 The failure on RH7.1 with their
stock 2.4.2 kernel  is

...
open("/lib/i686/libc.so.6", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\302"...,
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=5634864, ...}) = 0
old_mmap(NULL, 1242920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x40084000
mprotect(0x401aa000, 38696, PROT_NONE)  = 0
old_mmap(0x401aa000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x125000) 
= 0x401aa000
old_mmap(0x401b0000, 14120, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401b0000
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 
0x401b4000
munmap(0x4001c000, 71314)               = 0
getpid()                                = 21609
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++



on RH6.2 the working trace looks like this

...
old_mmap(0x40160000, 14428, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40160000
close(3)                                = 0
mprotect(0x4006f000, 970752, PROT_READ|PROT_WRITE) = 0
mprotect(0x4006f000, 970752, PROT_READ|PROT_EXEC) = 0
munmap(0x40015000, 28133)               = 0
personality(PER_LINUX)                  = 0
getpid()                                = 6255
fcntl(0, F_GETFD)                       = 0
fcntl(1, F_GETFD)                       = 0
fcntl(2, F_GETFD)                       = 0
brk(0)                                  = 0x87abd24
brk(0x87abd5c)                          = 0x87abd5c
brk(0x87ac000)                          = 0x87ac000
setrlimit(RLIMIT_FSIZE, {rlim_cur=2147483136, rlim_max=2147483136}) = 0
umask(0)                                = 02
gettimeofday({989118158, 278275}, NULL) = 0
getpid()              = 6255
stat("/opt/informix/etc/onconfig", {st_mode=S_IFREG|0644, st_size=7628,
...}) = 0
getuid()                                = 0
brk(0x87ad000)                          = 0x87ad000
...

Suspicions are with glibc 2.2.2.  But IDS7.3 works...

Any help is appreciated.

Comment 1 Jakub Jelinek 2001-06-06 14:37:29 UTC
Should be fixed in glibc-2.2.3-10.


Note You need to log in before you can comment on or make changes to this bug.