Irb Abort on Solaris Backtrace

ruby-talk
1

Hi:

Me again, with the silly Solaris problme on 1.7.3.
GDB shows this problem to be with SIGSEGV.

./ruby -v
ruby 1.7.3 (2002-12-04) [sparc-solaris2.8]

gdb ./ruby
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 “sparc-sun-solaris2.8”…
(gdb) r irb
Starting program: /home/jfn/ruby173/bin/ruby irb

Program received signal SIGSEGV, Segmentation fault.
0xff1c2afc in __do_global_ctors_aux ()
from /home/jfn/ruby173/lib/ruby/1.7/sparc-solaris2.8/nkf.so

(gdb) bt
#0 0xff1c2afc in __do_global_ctors_aux ()
from /home/jfn/ruby173/lib/ruby/1.7/sparc-solaris2.8/nkf.so
#1 0xff0f1358 in _init ()
from /home/jfn/ruby173/lib/ruby/1.7/sparc-solaris2.8/nkf.so
#2 0xff3bc1ec in ?? ()
#3 0xff3c0d34 in ?? ()
#4 0xff3c0e5c in ?? ()
#5 0x000e2274 in dln_load ( file=0x18f0c8
"/home/jfn/ruby173/lib/ruby/1.7/sparc-solaris2.8/nkf.so")
at dln.c:1322
#6 0x0002e2e0 in rb_f_require (obj=1404888, fname=2099384) at eval.c:5671
#7 0x000291b4 in call_cfunc (func=0x2dea8 <rb_f_require>, recv=1404888,
len=1, argc=1, argv=0xffbe9570) at eval.c:4464
#8 0x0002a130 in rb_call0 (klass=1410552, recv=1404888, id=8945, oid=8945,
argc=1, argv=0xffbe9570, body=0x147960, nosuper=1) at eval.c:4592
#9 0x0002afa4 in rb_call (klass=1410552, recv=1404888, mid=8945, argc=1,
argv=0xffbe9570, scope=1) at eval.c:4808
#10 0x000220e0 in rb_eval (self=1404888, n=0x2039c0) at eval.c:2771
#11 0x0001f770 in rb_eval (self=1404888, n=0x201560) at eval.c:2243
#12 0x0001bad8 in eval_node (self=1404888, node=0x201560) at eval.c:1126
#13 0x0002d5d4 in rb_load (fname=2112152, wrap=0) at eval.c:5439
#14 0x0002e53c in rb_f_require (obj=4, fname=2112248) at eval.c:5699
#15 0x000cb728 in rb_autoload_load (id=14317) at variable.c:1150
#16 0x000cb538 in top_const_get (id=14317, klassp=0xffbe9f04)
at variable.c:1109
#17 0x000cb7d4 in rb_const_get (klass=2113280, id=14317) at
variable.c:1167
#18 0x0001d5dc in ev_const_get (cref=0x203ea0, id=14317, self=2113280)
at eval.c:1563
#19 0x000234f0 in rb_eval (self=2113280, n=0x20da10) at eval.c:2995
#20 0x000235c4 in rb_eval (self=2113280, n=0x20d860) at eval.c:3018
#21 0x00023844 in rb_eval (self=2113280, n=0x20c930) at eval.c:3070
#22 0x000233a8 in rb_eval (self=2113280, n=0x20c840) at eval.c:2966
#23 0x0001f770 in rb_eval (self=2113280, n=0x20fed0) at eval.c:2243
#24 0x00025210 in module_setup (module=2113280, n=0x2040f8) at eval.c:3465
#25 0x0002484c in rb_eval (self=1244688, n=0x2040c8) at eval.c:3333
#26 0x00025210 in module_setup (module=1244688, n=0x204098) at eval.c:3465
#27 0x00024ab4 in rb_eval (self=1404888, n=0x210500) at eval.c:3368
#28 0x0001bad8 in eval_node (self=1404888, node=0x210500) at eval.c:1126
#29 0x0002d5d4 in rb_load (fname=2165696, wrap=0) at eval.c:5439
#30 0x0002e53c in rb_f_require (obj=1404888, fname=2165816) at eval.c:5699
#31 0x000291b4 in call_cfunc (func=0x2dea8 <rb_f_require>, recv=1404888,
len=1, argc=1, argv=0xffbeba08) at eval.c:4464
#32 0x0002a130 in rb_call0 (klass=1410552, recv=1404888, id=8945, oid=8945,
argc=1, argv=0xffbeba08, body=0x147960, nosuper=1) at eval.c:4592
#33 0x0002afa4 in rb_call (klass=1410552, recv=1404888, mid=8945, argc=1,
argv=0xffbeba08, scope=1) at eval.c:4808
#34 0x000220e0 in rb_eval (self=1404888, n=0x1454a0) at eval.c:2771
#35 0x0001f770 in rb_eval (self=1404888, n=0x145818) at eval.c:2243
#36 0x0001bad8 in eval_node (self=1404888, node=0x145818) at eval.c:1126
#37 0x0002d5d4 in rb_load (fname=1333944, wrap=0) at eval.c:5439
#38 0x0002e53c in rb_f_require (obj=1404888, fname=1334040) at eval.c:5699
#39 0x000291b4 in call_cfunc (func=0x2dea8 <rb_f_require>, recv=1404888,
len=1, argc=1, argv=0xffbec508) at eval.c:4464
#40 0x0002a130 in rb_call0 (klass=1410552, recv=1404888, id=8945,
oid=8945, argc=1, argv=0xffbec508, body=0x147960, nosuper=1) at eval.c:4592
#41 0x0002afa4 in rb_call (klass=1410552, recv=1404888, mid=8945, argc=1,
argv=0xffbec508, scope=1) at eval.c:4808
#42 0x000220e0 in rb_eval (self=1404888, n=0x146040) at eval.c:2771
#43 0x0001f770 in rb_eval (self=1404888, n=0x145c20) at eval.c:2243
#44 0x0001bad8 in eval_node (self=1404888, node=0x145c20) at eval.c:1126
#45 0x0001c274 in ruby_exec () at eval.c:1271
#46 0x0001c34c in ruby_run () at eval.c:1291
#47 0x00018f78 in main (argc=2, argv=0xffbeccf4, envp=0xffbecd00) at main.c:50

Any help here would be appreciated.
Thanks

···

–
Jim Freeze

An exotic journey in downtown Newark is in your future.

2

#0 0xff1c2afc in __do_global_ctors_aux ()

This is strange.

Do it crash with other extensions, like socket ?

Guy Decoux

3

I got it to work by static linking.
I will look into the ld option tomorrow.

···

On Tuesday, 10 December 2002 at 23:00:57 +0900, ts wrote:

> checking whether the linker is GNU ld... yes

Try to change this.

--
Jim Freeze
----------
No problem is so large it can't be fit in somewhere.

4

After looking into this issue more, it appears that ld is used
during runtime and not during compile time. (Is this true?)
Anyway, I still don't understand why an installed version of
1.6.6 works while 1.7.3 does not (that is, with the /usr/css/bin/ld).
All I have to do to get the 1.7.3 version to run is to ensure that
/usr/local/bin/ld is in my path before /usr/css/bin/ld.
Also, 1.6.7 partially works, that is, irb run but socket Aborts.

Has something changed with 1.7.3, or does ld link the .so files and
there is some wierd interaction between the the old .so files
and the new .so files?

···

On Wednesday, 11 December 2002 at 8:11:18 +0900, Jim Freeze wrote:

On Tuesday, 10 December 2002 at 23:28:59 +0900, Yukihiro Matsumoto wrote:
> I'm afraid your linker (GNU ld) is not capable to create dynamic
> loadable modules (.so), or maybe we need to specify some unknown
> command line options to the linker to do so. Do manual pages on your
> machine say anything? Try man dlopen, ld etc.
>
> matz.

Thanks much for your help. I just figured out that the default
path was recently changed to put /usr/ccs/bin before /usr/local/bin.
Changing this and placing /usr/local/bin first allowed the gnu ld
(/usr/local/bin/ld) to be used instead of solaris ld (/usr/ccs/bin/ld).
All problems have now disappeared.

--
Jim Freeze
----------
Krogt, n. (chemical symbol: Kr):
  The metallic silver coating found on fast-food game cards.
    -- Rich Hall, "Sniglets"

5

Anyway, I still don't understand why an installed version of
1.6.6 works while 1.7.3 does not (that is, with the /usr/css/bin/ld).
All I have to do to get the 1.7.3 version to run is to ensure that
/usr/local/bin/ld is in my path before /usr/css/bin/ld.

Try to see how your gcc was compiled. just create

nasun% cat a.c
main() {}
nasun%

then compile it with

  gcc -v a.c

and see if it call /usr/css/bin/{as,ld} or /usr/local/bin/{as,ld}

the version of "GNU ld" can be important.

Guy Decoux

6

Here is what I get (GNU ld version is 2.13):

gcc -v a.c
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs
gcc version 2.95.3 20010315 (release)
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/cpp0 -lang-c -v
-D__GNUC__=2 -D__GNUC_MINOR__=95 -Dsparc -Dsun -Dunix -D__svr4__
-D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc
-D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__
-Acpu(sparc) -Amachine(sparc) a.c /tmp/ccUQtf5n.i
GNU CPP version 2.95.3 20010315 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
   /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../sparc-sun-solaris2.8/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/include
/usr/include
End of search list.
The following default directories have been omitted from the search
path:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3
End of omitted list.
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/cc1
/tmp/ccUQtf5n.i -quiet -dumpbase a.c -version -o /tmp/ccOgwVOP.s
GNU C version 2.95.3 20010315 (release) (sparc-sun-solaris2.8)
compiled by GNU C version 2.95.3 20010315 (release).
/usr/local/sparc-sun-solaris2.8/bin/as -V -Qy -s -o
/tmp/ccF8TOBS.o /tmp/ccOgwVOP.s
GNU assembler version 2.13 (sparc-sun-solaris2.8) using BFD version 2.13
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/crt1.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/crti.o
/usr/ccs/lib/values-Xa.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/crtbegin.o
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3
-L/usr/local/sparc-sun-solaris2.8/lib -L/usr/ccs/bin
-L/usr/ccs/lib -L/usr/local/lib /tmp/ccF8TOBS.o -lgcc -lc -lgcc
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/crtend.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/crtn.o
GNU ld version 2.13
Supported emulations:
elf32_sparc
elf64_sparc

···

On Wednesday, 11 December 2002 at 19:51:48 +0900, ts wrote:

Try to see how your gcc was compiled. just create

nasun% cat a.c
main() {}
nasun%

then compile it with

  gcc -v a.c

and see if it call /usr/css/bin/{as,ld} or /usr/local/bin/{as,ld}

the version of "GNU ld" can be important.

--
Jim Freeze
----------
"I'm prepared for all emergencies but totally unprepared for everyday
life."

7

Here is what I get (GNU ld version is 2.13):

Well, we'll see if it work

nasun% cat a.c
#include <stdio.h>
#include <dlfcn.h>

int main(void)
{
    void *handle, *sym;
    char *error;

    puts("calling dlopen");
    handle = dlopen("./b.so", RTLD_NOW);
    if (!handle) {
        printf("%s\n", dlerror());
        return 1;
    }

    puts("calling dlsym");
    sym = dlsym(handle, "sym");
    if ((error = dlerror()) != 0) {
        printf("%s\n", error);
        return 1;
    }
    puts("calling sym");
    ((void (*)(void))sym)();
    puts("done");
    return 0;
}

nasun%

nasun% cat b.c
#include <stdio.h>
void sym(void)
{
    puts("in sym");
}
nasun%

and compile it

  gcc -fPic -shared b.c -o b.so
  gcc a.c -ldl

  ./a.out

Guy Decoux

8

gcc -fpic -shared b.c -o b.so # it didn't like -fPic
gcc a.c -ldl
./a.out
calling dlopen
Segmentation fault

···

On Wednesday, 11 December 2002 at 22:51:15 +0900, ts wrote:

  gcc -fPic -shared b.c -o b.so
  gcc a.c -ldl

  ./a.out

--
Jim Freeze
----------
If I don't see you in the future, I'll see you in the pasture.

9

gcc -fpic -shared b.c -o b.so # it didn't like -fPic

Yes, it was my fault

gcc a.c -ldl
./a.out
calling dlopen
Segmentation fault

It's broken your version of "GNU ld", it can't use shared library

Guy Decoux