public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nscd/9750] New: nscd gc() segmentation fault by estimation failure of alloca()'s stack usage
@ 2009-01-16 11:42 j-nomura at ce dot jp dot nec dot com
2009-01-29 0:18 ` [Bug nscd/9750] " drepper at redhat dot com
` (4 more replies)
0 siblings, 5 replies; 7+ messages in thread
From: j-nomura at ce dot jp dot nec dot com @ 2009-01-16 11:42 UTC (permalink / raw)
To: glibc-bugs
The garbage collection function, gc(), estimates the stack usage
to switch the allocation method.
For the allocation of 'struct moveinfo', it adds the size given to alloca().
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/nscd/mem.c.diff?r1=1.3.2.8&r2=1.3.2.9&cvsroot=glibc
In fucntion gc():
new_move = alloca (sizeof (*new_move));
stack_used += sizeof (*new_move);
However, alloca() seems to allocate additional +16 bytes for each allocation
in my case (Fedora 9, x86_64).
As a result, the estimation gets wrong and gc() ends up to segmentation fault.
Simply summing up the extra 16 bytes to the estimation would solve the problem.
Or if there is a better method to determine the current stack usage,
it might be better to switch the whole estimation stuff to use that.
--
Summary: nscd gc() segmentation fault by estimation failure of
alloca()'s stack usage
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: nscd
AssignedTo: drepper at redhat dot com
ReportedBy: j-nomura at ce dot jp dot nec dot com
CC: glibc-bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=9750
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nscd/9750] nscd gc() segmentation fault by estimation failure of alloca()'s stack usage
2009-01-16 11:42 [Bug nscd/9750] New: nscd gc() segmentation fault by estimation failure of alloca()'s stack usage j-nomura at ce dot jp dot nec dot com
@ 2009-01-29 0:18 ` drepper at redhat dot com
2009-01-29 4:31 ` j-nomura at ce dot jp dot nec dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: drepper at redhat dot com @ 2009-01-29 0:18 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2009-01-29 00:18 -------
I've fixed that in cvs by using real stack use information for x86-64.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://sourceware.org/bugzilla/show_bug.cgi?id=9750
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nscd/9750] nscd gc() segmentation fault by estimation failure of alloca()'s stack usage
2009-01-16 11:42 [Bug nscd/9750] New: nscd gc() segmentation fault by estimation failure of alloca()'s stack usage j-nomura at ce dot jp dot nec dot com
2009-01-29 0:18 ` [Bug nscd/9750] " drepper at redhat dot com
@ 2009-01-29 4:31 ` j-nomura at ce dot jp dot nec dot com
2009-01-29 5:24 ` j-nomura at ce dot jp dot nec dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: j-nomura at ce dot jp dot nec dot com @ 2009-01-29 4:31 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From j-nomura at ce dot jp dot nec dot com 2009-01-29 04:31 -------
Thank you for the fix on x86_64, but I confirmed the same problem occurs on i386
system.
(alloca() pads the extra 16 bytes on Fedora 9 i386, too.
May also on other archs but I don't have machines to check with.)
Could you put a "%%esp" version of the stackinfo_get_sp/stackinfo_sub_sp macros
to sysdeps/i386, too?
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/x86_64/stackinfo.h.diff?r1=1.1&r2=1.2&cvsroot=glibc
Also, the following fallback macro in alloca.h doesn't compile anyway:
# define alloca_account(size, avar) \
({ size_t s__ = (size); \
avar += size__; \
__alloca (size__); })
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/include/alloca.h.diff?r1=1.8&r2=1.9&cvsroot=glibc
Should "s__" be "size__"?
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
http://sourceware.org/bugzilla/show_bug.cgi?id=9750
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nscd/9750] nscd gc() segmentation fault by estimation failure of alloca()'s stack usage
2009-01-16 11:42 [Bug nscd/9750] New: nscd gc() segmentation fault by estimation failure of alloca()'s stack usage j-nomura at ce dot jp dot nec dot com
2009-01-29 0:18 ` [Bug nscd/9750] " drepper at redhat dot com
2009-01-29 4:31 ` j-nomura at ce dot jp dot nec dot com
@ 2009-01-29 5:24 ` j-nomura at ce dot jp dot nec dot com
2009-01-29 5:28 ` j-nomura at ce dot jp dot nec dot com
2009-02-07 4:29 ` drepper at redhat dot com
4 siblings, 0 replies; 7+ messages in thread
From: j-nomura at ce dot jp dot nec dot com @ 2009-01-29 5:24 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From j-nomura at ce dot jp dot nec dot com 2009-01-29 05:24 -------
In case anyone have archs other than i386/x86_64, try the following test program
to see whether the default alloca_account works.
----------------------------------------------------------------------------
#include <stdio.h>
#include <alloca.h>
#if !defined(alloca_account)
#define alloca_account(size, avar) \
({ size_t size__ = (size); \
avar += size__; \
alloca (size__); })
#endif
int test_alloc_size[] = { 4, 8, 16, 32, 48, 64, 100, };
void
test_alloca(size_t sz)
{
int i;
char *cur, *prev;
int stk_usage = 0, stk_usage_real = 0;
printf("unit allocation size = %d\n", sz);
prev = alloca(sz);
for (i = 0; i < 3; i++) {
cur = alloca_account(sz, stk_usage);
stk_usage_real += prev - cur;
prev = cur;
printf("# [%d] stack used: %d (accounted as %d)\n",
i, stk_usage_real, stk_usage);
}
if (stk_usage != stk_usage_real)
printf("FAIL: accounted usage differs from the real usage\n");
else
printf("PASS\n");
printf("\n");
}
int
main(int argc, char **argv)
{
int n = 0;
while (test_alloc_size[n]) {
test_alloca(test_alloc_size[n]);
n++;
}
}
----------------------------------------------------------------------------
--
http://sourceware.org/bugzilla/show_bug.cgi?id=9750
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nscd/9750] nscd gc() segmentation fault by estimation failure of alloca()'s stack usage
2009-01-16 11:42 [Bug nscd/9750] New: nscd gc() segmentation fault by estimation failure of alloca()'s stack usage j-nomura at ce dot jp dot nec dot com
` (2 preceding siblings ...)
2009-01-29 5:24 ` j-nomura at ce dot jp dot nec dot com
@ 2009-01-29 5:28 ` j-nomura at ce dot jp dot nec dot com
2009-02-07 4:29 ` drepper at redhat dot com
4 siblings, 0 replies; 7+ messages in thread
From: j-nomura at ce dot jp dot nec dot com @ 2009-01-29 5:28 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From j-nomura at ce dot jp dot nec dot com 2009-01-29 05:27 -------
Oops, sorry.
In the previous comment, this:
int test_alloc_size[] = { 4, 8, 16, 32, 48, 64, 100, };
should be:
int test_alloc_size[] = { 4, 8, 16, 32, 48, 64, 100, 0, };
--
http://sourceware.org/bugzilla/show_bug.cgi?id=9750
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nscd/9750] nscd gc() segmentation fault by estimation failure of alloca()'s stack usage
2009-01-16 11:42 [Bug nscd/9750] New: nscd gc() segmentation fault by estimation failure of alloca()'s stack usage j-nomura at ce dot jp dot nec dot com
` (3 preceding siblings ...)
2009-01-29 5:28 ` j-nomura at ce dot jp dot nec dot com
@ 2009-02-07 4:29 ` drepper at redhat dot com
4 siblings, 0 replies; 7+ messages in thread
From: drepper at redhat dot com @ 2009-02-07 4:29 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2009-02-07 04:29 -------
Don't attach comments without keeping the bug FIXED.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
http://sourceware.org/bugzilla/show_bug.cgi?id=9750
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nscd/9750] nscd gc() segmentation fault by estimation failure of alloca()'s stack usage
[not found] <bug-9750-131@http.sourceware.org/bugzilla/>
@ 2014-07-01 21:19 ` fweimer at redhat dot com
0 siblings, 0 replies; 7+ messages in thread
From: fweimer at redhat dot com @ 2014-07-01 21:19 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=9750
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-07-01 21:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-16 11:42 [Bug nscd/9750] New: nscd gc() segmentation fault by estimation failure of alloca()'s stack usage j-nomura at ce dot jp dot nec dot com
2009-01-29 0:18 ` [Bug nscd/9750] " drepper at redhat dot com
2009-01-29 4:31 ` j-nomura at ce dot jp dot nec dot com
2009-01-29 5:24 ` j-nomura at ce dot jp dot nec dot com
2009-01-29 5:28 ` j-nomura at ce dot jp dot nec dot com
2009-02-07 4:29 ` drepper at redhat dot com
[not found] <bug-9750-131@http.sourceware.org/bugzilla/>
2014-07-01 21:19 ` fweimer at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).