The system is a Slackware -current.
$ uname -srvmpio 
Linux 3.8.13-smp #2 SMP Sun May 12 19:59:29 CDT 2013 i686 Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz GenuineIntel GNU/Linux
$ gcc -dumpversion
4.8.0

Hi!

(In reply to comment #0)
> I'm trying to use the fresh 0.5.[01] libbsd, and when starting the program
> that I link with it, I get a segfault. I've tried with two different
> softwares that link against libbsd, and got the same segmentation fault:
> 
> [...]
> Program terminated with signal 11, Segmentation fault.
> #0  0xb75f92c8 in spt_init (argc=-1218455576, argv=0x1, envp=0x1) at
> setproctitle.c:138
> 138             base = argv[0];
> (gdb) bt
> #0  0xb75f92c8 in spt_init (argc=-1218455576, argv=0x1, envp=0x1) at
> setproctitle.c:138
> #1  0xb75faf6d in __do_global_ctors_aux () from /usr/lib/libbsd.so.0

Ok, so this looks like the spt_init constructor function ends up in the .ctor
section as it's being called from the code handling that section, instead of
in .init_array, and the calls into the .ctor function do not get passed the
needed arguments.

Could you check your binary with something like:

  objdump -s -j .init_array -j .init -j .ctor program-name

> Everything worked fine with 0.4.2 -- but of course, it didn't have
> setproctitle.

What libc and binutils versions are you using?

I guess I'll have to make sure in configure that the constructor
functions ends up in the correct section (i.e. not in .ctor), to avoid this.

(In reply to comment #2)
> Hi!
> 
> (In reply to comment #0)
> > I'm trying to use the fresh 0.5.[01] libbsd, and when starting the program
> > that I link with it, I get a segfault. I've tried with two different
> > softwares that link against libbsd, and got the same segmentation fault:
> > 
> > [...]
> > Program terminated with signal 11, Segmentation fault.
> > #0  0xb75f92c8 in spt_init (argc=-1218455576, argv=0x1, envp=0x1) at
> > setproctitle.c:138
> > 138             base = argv[0];
> > (gdb) bt
> > #0  0xb75f92c8 in spt_init (argc=-1218455576, argv=0x1, envp=0x1) at
> > setproctitle.c:138
> > #1  0xb75faf6d in __do_global_ctors_aux () from /usr/lib/libbsd.so.0
> 
> Ok, so this looks like the spt_init constructor function ends up in the .ctor
> section as it's being called from the code handling that section, instead of
> in .init_array, and the calls into the .ctor function do not get passed the
> needed arguments.

Hey Guillem,

Thanks for the explanation!

> Could you check your binary with something like:
> 
>   objdump -s -j .init_array -j .init -j .ctor program-name

Sure:


./kc:     file format elf32-i386

Contents of section .init:
 8049b28 5383ec08 e83f0800 0081c3df e500008b  S....?..........
 8049b38 83fcffff ff85c074 05e83a01 0000e805  .......t..:.....
 8049b48 090000e8 809e0000 83c4085b c3        ...........[.   


/bin/pdksh:     file format elf32-i386

Contents of section .init:
 80498f0 5383ec08 e8770800 0081c3ef 9703008b  S....w..........
 8049900 83fcffff ff85c074 05e87203 0000e83d  .......t..r....=
 8049910 090000e8 48f40200 83c4085b c3        ....H......[.   

> > Everything worked fine with 0.4.2 -- but of course, it didn't have
> > setproctitle.
> 
> What libc and binutils versions are you using?

glibc is at 2.17, and my binutils package is version 2.23.52.0.1.

> I guess I'll have to make sure in configure that the constructor
> functions ends up in the correct section (i.e. not in .ctor), to avoid this.

(In reply to comment #3)
> (In reply to comment #2)
> > Could you check your binary with something like:
> > 
> >   objdump -s -j .init_array -j .init -j .ctor program-name

Sorry that should have been (.ctors instead of .ctor):

  objdump -s -j .init_array -j .init -j .ctors program-name

In any case, the problem here is that there's no .init_array section.

> > > Everything worked fine with 0.4.2 -- but of course, it didn't have
> > > setproctitle.
> > 
> > What libc and binutils versions are you using?
> 
> glibc is at 2.17, and my binutils package is version 2.23.52.0.1.

Hmm, ok could you check if your distribution builds for binutils and gcc
have perhaps disabled the .init_array/.fini_array native support, there's
a flag for those (--enable-initfini-array), or maybe the checks to see if
these are supported failed?

Meanwhile, a workaround in libbsd until you figure out why .init_array is
not generated on your distribution could be the attached patch. I guess I
can make libbsd switch to use that if the constructor is not placed in
.init_array either by gcc directly, or by ld converting .ctors to .init_array.

Created attachment 79908 [details] [review]
Force spt_init into the .init_array section

(In reply to comment #4)
[...]
> > >   objdump -s -j .init_array -j .init -j .ctor program-name
> 
> Sorry that should have been (.ctors instead of .ctor):
> 
>   objdump -s -j .init_array -j .init -j .ctors program-name

Rrrright, should've catch that, sorry ... :)


$ objdump -s -j .init_array -j .init -j .ctors ./kc

./kc:     file format elf32-i386

Contents of section .init:
 8049b28 5383ec08 e83f0800 0081c3df e500008b  S....?..........
 8049b38 83fcffff ff85c074 05e83a01 0000e805  .......t..:.....
 8049b48 090000e8 809e0000 83c4085b c3        ...........[.   
Contents of section .ctors:
 8058000 ffffffff 00000000                    ........        


$ objdump -s -j .init_array -j .init -j .ctors /bin/pdksh

/bin/pdksh:     file format elf32-i386

Contents of section .init:
 80498f0 5383ec08 e86b0800 0081c3ef a703008b  S....k..........
 8049900 83fcffff ff85c074 05e87203 0000e82d  .......t..r....-
 8049910 090000e8 08fe0200 83c4085b c3        ...........[.   
Contents of section .ctors:
 8084000 ffffffff 00000000                    ........

> In any case, the problem here is that there's no .init_array section.

[...]
> > glibc is at 2.17, and my binutils package is version 2.23.52.0.1.
> 
> Hmm, ok could you check if your distribution builds for binutils and gcc
> have perhaps disabled the .init_array/.fini_array native support, there's
> a flag for those (--enable-initfini-array), or maybe the checks to see if
> these are supported failed?

Your suspicion was right. From the binutils build script for my distribution:

[...]
# The --enable-initfini-array option was added in binutils-2.21.51.0.3.
# This option currently causes a world of hurt trying to compile glibc,
# and might break static libraries or cause other ill effects.  There
# is an upstream patch for glibc but it does not avoid all of the known
# problems (and there may be some unknown ones, too), so we will avoid
# introducing this feature for now.
# References:
# http://sourceware.org/bugzilla/show_bug.cgi?id=12343
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
NO_INITFINI=" --disable-initfini-array "
[...]
./configure \
[...]
  $NO_INITFINI \
[...]


> Meanwhile, a workaround in libbsd until you figure out why .init_array is
> not generated on your distribution could be the attached patch. I guess I
> can make libbsd switch to use that if the constructor is not placed in
> .init_array either by gcc directly, or by ld converting .ctors to
> .init_array.

The attached patch with the workaround solved this issue for me. objdump(1) shows the same
stuff, but now the binaries run.
Thanks!


Daniel

Fixed in 0.5.2.