Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 80033 - guile: libguile function scm_init_guile() aborts
Summary: guile: libguile function scm_init_guile() aborts
Status: VERIFIED NEEDINFO
Alias: None
Product: Community Relations
Classification: Unclassified
Component: Developer Relations (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Alastair Tse (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-30 00:38 UTC by Paul Osmialowski
Modified: 2005-06-25 12:03 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Osmialowski 2005-01-30 00:38:54 UTC
On freshly installed gentoo system I've compiled some program that I was using for months on FC3. Both systems have guile 1.6.4. Most important difference is that gentoo was compiled with -fstack-protector CFLAGS option put into /etc/make.conf. I've tried to emerge guile without this option and compile my program with -fno-stack-protector option but it didn't change anything: my program aborts on function scm_init_guile();

Reproducible: Always
Steps to Reproduce:
1. create some file, say libguile.c:
#include <libguile.h>
#include <stdio.h>

int main()
{
    printf("Initializing Scheme... "); fflush(stdout);
    scm_init_guile();
    printf("OK\n");
    return 0;
}
2. compile it:
cc -Wall -o libguile libguile.c `guile-config compile` `guile-config link`
3. run:
./libguile

Actual Results:  
Initializing Scheme... Aborted


Expected Results:  
Initializing Scheme... OK


$ uname -a
Linux bajka 2.4.28-hardened-r3 #2 SMP Thu Jan 27 11:22:23 CET 2005 i686 Pentium
Pro GenuineIntel GNU/Linux
$ cat /etc/make.conf
CFLAGS="-O2 -mcpu=i686 -fomit-frame-pointer -fstack-protector"
CHOST="i386-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j1"
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 1
model name      : Pentium Pro
stepping        : 9
cpu MHz         : 199.439
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
bogomips        : 398.13

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 1
model name      : Pentium Pro
stepping        : 9
cpu MHz         : 199.439
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
bogomips        : 398.13
Comment 1 Paul Osmialowski 2005-01-30 01:04:20 UTC
I've just checked the dmesgs and found:
grsec: signal 6 sent to /home/newchief/libguile[libguile:14194] uid/euid:1000/1000 gid/egid:407/407, parent /bin/bash[bash:19261] uid/euid:1000/1000 gid/egid:407/407
grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /home/newchief/libguile[libguile:14194] uid/euid:1000/1000 gid/egid:407/407, parent /bin/bash[bash:19261] uid/euid:1000/1000 gid/egid:407/407
That's the reason for the nasty behavior.
Comment 2 Tim Yamin (RETIRED) gentoo-dev 2005-01-30 06:18:09 UTC
Please don't file bugs under the Gentoo Developer Relations bug product unless you need to log a human resources issue. File bugs under the Gentoo Linux product.
Comment 3 Stian Skjelstad 2005-06-17 09:01:44 UTC
could you do a strace to verify/invalidate that rlimit is the cause of the
signal, and that it doesn't come from a signal-handler inside libguile.
Comment 4 Alastair Tse (RETIRED) gentoo-dev 2005-06-25 10:30:55 UTC
need more info before we can verify this bug.
Comment 5 Paul Osmialowski 2005-06-25 12:03:49 UTC
During recent kernel upgrade I've chosen less intrusive options of grsecurity
and now I'm able to use libguile depending programs, so I think, case is closed.
I was suspecting stack-protector to be the reason of the failure, but it wasn't.
The only problem was the grsecurity kernel options concerning executables.