Summary: | guile: libguile function scm_init_guile() aborts | ||
---|---|---|---|
Product: | Community Relations | Reporter: | Paul Osmialowski <newchief> |
Component: | Developer Relations | Assignee: | Alastair Tse (RETIRED) <liquidx> |
Status: | VERIFIED NEEDINFO | ||
Severity: | normal | CC: | stian |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Paul Osmialowski
2005-01-30 00:38:54 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. 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. 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. need more info before we can verify this bug. 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. |