Slackware 64 - Static compilation broken !

NoStressHQ · 05-13-2010, 08:54 PM

Sorry, it's been a while. I had other things to work on on Window$ system and couldn't really check this since last week.

Anyway I tried to check the ubuntu stuff I found last time, but honestly I'm quite lost into that ubuntu patch list, (and I haven't much time to spend on this too), I've seen few things that "looks like but are not", I think what I'd really need is to forget about the diff but trying to trace into the 'signal' call to see what parameters are sent to the kernel system call by glibc, and try to figure out why it's broken.

Right now I don't have time to look into this, but a quick thinking makes ask if the debug infos are provided in the slackware standard build. I'm afraid that I'll have to patch the slackbuild to do this (the easy part) and rebuild the whole stuff to have access to the source file symbols... Maybe it's the way to go, and in a sense I'd rather do that, than trying to understand a distro I'll never use

.

Of course if someone is brave enough, have the time, and have the knowledge of both ubuntu and slackware builds internals, and can find a clue the diff way, you're welcome ! (Yes that's an if with a lots of 'ands'...

)

I keep you informed if I have some fresh news.

Cheers

Garry

bgeddy · 05-13-2010, 09:41 PM

I too haven't had time to examine this, (although I want to as these are the types of problems that fascinate me), so good luck and please do keep us posted on any findings. I will do likewise if I get the time to explore this some more.

brianL · 05-14-2010, 04:31 AM

I did some more googling on "segmentation fault", and found this page:

http://gcc.gnu.org/bugs/segfault.html

So I tried compiling gazl-sig.c with this:

Code:

gcc -Wall -O0 -g -v -da -Q -static gazl-sig.c -o sig-static

This produced this load of files:

Code:

gazl-sig.c.138r.jump		gazl-sig.c.175r.lreg		      gazl-sig.c.201r.barriers
gazl-sig.c.157r.regclass	gazl-sig.c.176r.greg		      gazl-sig.c.204r.eh-ranges
gazl-sig.c.131r.expand		gazl-sig.c.160r.outof_cfglayout       gazl-sig.c.177r.subregs_of_mode_finish  gazl-sig.c.205r.shorten
gazl-sig.c.132r.sibling		gazl-sig.c.166r.split1		      gazl-sig.c.180r.split2		      gazl-sig.c.206r.dfinish
gazl-sig.c.134r.initvals	gazl-sig.c.168r.dfinit		      gazl-sig.c.182r.pro_and_epilogue	      
gazl-sig.c.135r.unshare		gazl-sig.c.169r.mode-sw		      gazl-sig.c.196r.stack
gazl-sig.c.136r.vregs		gazl-sig.c.171r.asmcons		      gazl-sig.c.197r.alignments
gazl-sig.c.137r.into_cfglayout	gazl-sig.c.174r.subregs_of_mode_init  gazl-sig.c.200r.mach

Like I said before, I've no idea what I'm doing or looking for, but it's interesting ( if that makes any sense to anyone else

). If the name of any of those files offers a clue to anybody, I'll post it.

GazL · 05-14-2010, 05:25 AM

I think that page is about debugging segmentation faults during the compilation process brian. I don't think it's going to be much help.

I've not managed to get any further with this one. How about you Garry?

brianL · 05-14-2010, 08:57 AM

I've tried strace on both the Slack & the Ubuntu versions. Anything significant here:

Code:

execve("./sig-static", ["./sig-static"], [/* 52 vars */]) = 0
uname({sys="Linux", node="SlackB", ...}) = 0
brk(0)                                  = 0x696000
brk(0x696f10)                           = 0x696f10
arch_prctl(ARCH_SET_FS, 0x696850)       = 0
brk(0x6b7f10)                           = 0x6b7f10
brk(0x6b8000)                           = 0x6b8000
rt_sigaction(SIGALRM, {0x4002ac, [], SA_RESTORER, 0xf0000000fc0c748}, {SIG_DFL, [], 0}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={0, 100}, it_value={0, 100}}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7904b8a000
write(1, "Tick!\n"..., 6)               = 6
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

Code:

execve("./sig-static", ["./sig-static"], [/* 38 vars */]) = 0
uname({sys="Linux", node="brisbuntu", ...}) = 0
brk(0)                                  = 0x2115000
brk(0x2115f10)                          = 0x2115f10
arch_prctl(ARCH_SET_FS, 0x2115850)      = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "F\264\336\265\26+\267"..., 7)  = 7
close(3)                                = 0
brk(0x2136f10)                          = 0x2136f10
brk(0x2137000)                          = 0x2137000
rt_sigaction(SIGALRM, {0x4002e4, [], SA_RESTORER, 0x400b80}, {SIG_DFL}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={0, 100}, it_value={0, 100}}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8acc9b5000
write(1, "Tick!\n"..., 6Tick!
)               = 6
rt_sigreturn(0x1)                       = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
write(1, "Tick!\n"..., 6Tick!
)               = 6

I've cut the rest of the ticks.

GazL · 05-14-2010, 10:28 AM

I can see what looks like the bad return address being passed into rt_sigaction(), but I don't fully understand the strace syntax (what the square/curly brackets mean for example *1 ).

Slack:

Code:

rt_sigaction(SIGALRM, {0x4002ac, [], SA_RESTORER, 0xf0000000fc0c748}, {SIG_DFL, [], 0}, 8) = 0

Ubuntu:

Code:

rt_sigaction(SIGALRM, {0x4002e4, [], SA_RESTORER, 0x400b80}, {SIG_DFL}, 8) = 0

Still doesn't answer the question why it's happening, but it's another piece of the puzzle. Thanks brian. I think that is useful.

edit:

*1 Ahh the { } surround structs by the look of it. And it looks like "[ ]" is a representation of a NULL pointer. Cool. learnt something new.

brianL · 05-14-2010, 11:25 AM

Has this difference any significance? These lines, present in the Ubuntu output, but not the Slack. It's the first thing I noticed:

Code:

open("/dev/urandom", O_RDONLY)          = 3
read(3, "F\264\336\265\26+\267"..., 7)  = 7
close(3)                                = 0

GazL · 05-14-2010, 11:37 AM

Ok, I may be barking up completely the wrong tree here as I'm totally out of my depth. but I got to thinking that perhaps it's a header issue so I started poking around....

This is the definition of sigaction from slackware's /usr/include/bits/sigaction.h which is #included from /usr/include/signal.h

Code:

/* Structure describing the action to be taken when a signal arrives.  */
struct sigaction
  {
    /* Signal handler.  */
#ifdef __USE_POSIX199309
    union
      {
        /* Used if SA_SIGINFO is not set.  */
        __sighandler_t sa_handler;
        /* Used if SA_SIGINFO is set.  */
        void (*sa_sigaction) (int, siginfo_t *, void *);
      }
    __sigaction_handler;
# define sa_handler     __sigaction_handler.sa_handler
# define sa_sigaction   __sigaction_handler.sa_sigaction
#else
    __sighandler_t sa_handler;
#endif

    /* Additional set of signals to be blocked.  */
    __sigset_t sa_mask;

    /* Special flags.  */
    int sa_flags;

    /* Restore handler.  */
    void (*sa_restorer) (void);
  };

Now, here's the def from /usr/src/linux/include/asm-generic/signal.h:

Code:

struct sigaction {
        __sighandler_t sa_handler;
        unsigned long sa_flags;
#ifdef SA_RESTORER
        __sigrestore_t sa_restorer;
#endif
        sigset_t sa_mask;               /* mask last for extensibility */
};

struct k_sigaction {
        struct sigaction sa;
};

typedef struct sigaltstack {
        void __user *ss_sp;
        int ss_flags;
        size_t ss_size;
} stack_t;

Notice the different types (highlighted red). This may be perfectly valid, but as sa_flags comes directly before sa_restorer, which is the value we're having issues with it got me wondering. Also, sa_mask seems to come in a different place within the struct.

Brian, can you please compare these with the header files on on ubuntu, to see whether there's a cat in my tree or not.

GazL · 05-14-2010, 11:40 AM

Quote:

Originally Posted by brianL

Has this difference any significance? These lines, present in the Ubuntu output, but not the Slack. It's the first thing I noticed:

Code:

open("/dev/urandom", O_RDONLY)          = 3
read(3, "F\264\336\265\26+\267"..., 7)  = 7
close(3)                                = 0

I don't think so. Might be something to do with ubuntu's grsec kernel or something like that using random values for something or other.

brianL · 05-14-2010, 11:48 AM

Right, thanks. Any more diagnostic/analytic tools I can try on the different versions?

gnashley · 05-14-2010, 12:24 PM

GazL, you may be on to something with the difference in the headers. ubuntu patches the kernel headers because of some which are missing from a normal 'make headers_install' command -they may also be overwriting or patching the signal.h file

You might try a quick test by changing this:
int sa_flags;
to this:
unsigned long sa_flags;
in your /usr/include/bits/sigaction.h.

brianL · 05-14-2010, 01:40 PM

That part of sigactions.h is the same in Ubuntu, but /src/linux-*/include/asm-generic/signal.h is quite different. This is it, the whole thing:

Code:

#ifndef __ASM_GENERIC_SIGNAL_H
#define __ASM_GENERIC_SIGNAL_H

#include <linux/compiler.h>

#ifndef SIG_BLOCK
#define SIG_BLOCK          0	/* for blocking signals */
#endif
#ifndef SIG_UNBLOCK
#define SIG_UNBLOCK        1	/* for unblocking signals */
#endif
#ifndef SIG_SETMASK
#define SIG_SETMASK        2	/* for setting the signal mask */
#endif

#ifndef __ASSEMBLY__
typedef void __signalfn_t(int);
typedef __signalfn_t __user *__sighandler_t;

typedef void __restorefn_t(void);
typedef __restorefn_t __user *__sigrestore_t;

#define SIG_DFL	((__force __sighandler_t)0)	/* default signal handling */
#define SIG_IGN	((__force __sighandler_t)1)	/* ignore signal */
#define SIG_ERR	((__force __sighandler_t)-1)	/* error return from signal */
#endif

#endif /* __ASM_GENERIC_SIGNAL_H */

GazL · 05-14-2010, 02:21 PM

Ahh ok. I guess Ubuntu isn't the best of comparisons since they make so many changes to it. Thanks for putting in the effort.

@gnashley

Thanks for that. I'm not sure it's as simple as that though. Firstly, the sa_mask member of struct sigaction appears to be in different order between those two head files (before sa_restorer in one, and after in the other). Also, if any of the signal handling routines within libc.a change those structures, and if libc.a was built using a defective header then that will probably also need rebuilding once the header has been corrected as that error will have already been compiled into the library objects.

As Ubuntu isn't such a good basis for comparision, I might invest a little time and see if I can do the first few steps of a LFS install to get as clean a library/headers as I can for comparisons sake.
Might take me a while though, so anyone else looking at this please feel free to do your own investigations. I'll report back if I find anything interesting.

ponce · 05-14-2010, 05:47 PM

looks like this thing is fixed in -rc1

Alien Bob · 05-14-2010, 06:16 PM

Quote:

Originally Posted by ponce

looks like this thing is fixed in -rc1

Yes.

On the most recent -current:

Code:

alien@slack64:~$ vi test.sh

wrote test.sh, 67 lines, 1314 chars
alien@slack64:~$ sh test.sh 
 * Generating source...
 * Generating build script...
eha@slack64:~$ ./tst-sigalrm-build 
 * Shared run :
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
 * Static run :
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
Tick !
alien@slack64:~$

Eric