LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-13-2010, 08:54 PM   #31
NoStressHQ
Member
 
Registered: Apr 2010
Location: Lausanne - Switzerland ( Bordeaux - France / Montreal - QC - Canada)
Distribution: Slackware Leet - 32/64bit
Posts: 284

Original Poster
Rep: Reputation: 95

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
 
Old 05-13-2010, 09:41 PM   #32
bgeddy
Senior Member
 
Registered: Sep 2006
Location: Liverpool - England
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810

Rep: Reputation: 227Reputation: 227Reputation: 227
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.
 
Old 05-14-2010, 04:31 AM   #33
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,040
Blog Entries: 52

Rep: Reputation: Disabled
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.

Last edited by brianL; 05-14-2010 at 04:34 AM.
 
Old 05-14-2010, 05:25 AM   #34
GazL
Senior Member
 
Registered: May 2008
Posts: 3,426

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
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?
 
Old 05-14-2010, 08:57 AM   #35
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,040
Blog Entries: 52

Rep: Reputation: Disabled
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.
 
Old 05-14-2010, 10:28 AM   #36
GazL
Senior Member
 
Registered: May 2008
Posts: 3,426

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
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.

Last edited by GazL; 05-14-2010 at 10:44 AM.
 
Old 05-14-2010, 11:25 AM   #37
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,040
Blog Entries: 52

Rep: Reputation: Disabled
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
 
Old 05-14-2010, 11:37 AM   #38
GazL
Senior Member
 
Registered: May 2008
Posts: 3,426

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
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.

Last edited by GazL; 05-14-2010 at 11:47 AM.
 
Old 05-14-2010, 11:40 AM   #39
GazL
Senior Member
 
Registered: May 2008
Posts: 3,426

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
Quote:
Originally Posted by brianL View Post
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.
 
Old 05-14-2010, 11:48 AM   #40
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,040
Blog Entries: 52

Rep: Reputation: Disabled
Right, thanks. Any more diagnostic/analytic tools I can try on the different versions?
 
Old 05-14-2010, 12:24 PM   #41
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,763

Rep: Reputation: 471Reputation: 471Reputation: 471Reputation: 471Reputation: 471
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.
 
Old 05-14-2010, 01:40 PM   #42
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,040
Blog Entries: 52

Rep: Reputation: Disabled
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 */
 
Old 05-14-2010, 02:21 PM   #43
GazL
Senior Member
 
Registered: May 2008
Posts: 3,426

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
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.
 
Old 05-14-2010, 05:47 PM   #44
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,457

Rep: Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886
looks like this thing is fixed in -rc1
 
Old 05-14-2010, 06:16 PM   #45
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,300

Rep: Reputation: Disabled
Quote:
Originally Posted by ponce View Post
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
 
  


Reply

Tags
gcc, glibc, linking, programming, slackware, static


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Static ip prob in slackware 12.2 netpumber Slackware 12 02-15-2009 08:44 AM
static library cross compilation kskkumar Programming 3 03-20-2007 12:35 PM
slackware current broken? sweetnsourbkr Slackware 8 03-11-2006 06:26 AM
Static Bind Applications to Kernel; cross compilation Alybyzrp Linux - Newbie 0 11-25-2003 01:38 PM
static compilation of Qt programs tb_4js Linux - Software 0 04-25-2003 08:13 AM


All times are GMT -5. The time now is 07:52 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration