* [Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes
2005-12-02 17:21 [Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes burnus at gmx dot de
@ 2005-12-09 7:11 ` kukuk at suse dot de
2005-12-09 11:53 ` burnus at gmx dot de
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: kukuk at suse dot de @ 2005-12-09 7:11 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From kukuk at suse dot de 2005-12-09 07:11 -------
(In reply to comment #0)
> If I have a group with many entries (`/usr/bin/getent group test |wc -c
> ` > 1024), getgrnam() duely returns the entry whereas getgrnam_r() has some
> troubles.
>
> a) sysconf(_SC_GETGR_R_SIZE_MAX);
> returns always 1024, which is not large enough, but as there is ENORANGE, it is
> not too bad.
> SUSv3: "_SC_GETGR_R_SIZE_MAX Maximum size of getgrgid_r() and getgrnam_r() data
> buffers" and "The maximum size needed for this buffer [3rd argument of
> getgrnam_r] can be determined with the {_SC_GETGR_R_SIZE_MAX} sysconf()
parameter."
>
>
> b) Using getgrnam_r() with a big group and a too small buffer =
> _SC_GETGR_R_SIZE_MAX == 1024:
> (i) group: files (in /etc/nsswitch.conf)
> returned value: ERANGE, which is ok
> (ii) group: compat (in /etc/nsswitch.conf)
> getgrnam_r crashes with a memory access error.
> Expected: ERANGE or e.g. EIO.
>
> c) Using getgrnam_r() with a buffer bigger than 1024
> (i) entry < 1024: Ok
> (ii) entry > 1024 (independent of group:files vs. group:compat)
> Memory access error
As I told you already in Novell bugzilla: Your testprogram works fine and does
not crash for me:
_SC_GETGR_R_SIZE_MAX = 2048
mygetgrnam("testg", 1024) returned: ERANGE
DONE
So please explain exactly how to reproduce and deliver a backtrace.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |kukuk at suse dot de
http://sourceware.org/bugzilla/show_bug.cgi?id=1970
------- 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] 8+ messages in thread* [Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes
2005-12-02 17:21 [Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes burnus at gmx dot de
2005-12-09 7:11 ` [Bug libc/1970] " kukuk at suse dot de
@ 2005-12-09 11:53 ` burnus at gmx dot de
2005-12-09 12:00 ` burnus at gmx dot de
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: burnus at gmx dot de @ 2005-12-09 11:53 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From burnus at gmx dot de 2005-12-09 11:53 -------
> _SC_GETGR_R_SIZE_MAX = 2048
> mygetgrnam("testg", 1024) returned: ERANGE
Hmm, _SC_GETGR_R_SIZE_MAX = 2048 is interesting. What do you have in
/etc/nsswitch.conf? I get the crash only with compat, with file I also get ERANGE.
(gdb) run test
Starting program: /tmp/getent_test test
_SC_GETGR_R_SIZE_MAX = 1024
[... working getgrnam_r ...]
Call getgrnam_r(name = "test", grp, buffer, bufsize=1024,result)
Program received signal SIGSEGV, Segmentation fault.
0x401a7c10 in memchr () from /lib/tls/libc.so.6
(gdb) bt
#0 0x401a7c10 in memchr () from /lib/tls/libc.so.6
#1 0x00000000 in ?? ()
#2 0x000003ff in ?? ()
#3 0x401931dd in _IO_getline_info_internal () from /lib/tls/libc.so.6
#4 0x4019314f in _IO_getline_internal () from /lib/tls/libc.so.6
#5 0x4019b11a in fgets_unlocked () from /lib/tls/libc.so.6
#6 0x40019f2f in _nss_compat_getgrnam_r () from /lib/libnss_compat.so.2
#7 0x401c7354 in getgrnam_r@@GLIBC_2.1.2 () from /lib/tls/libc.so.6
#8 0x08048888 in mygetgrnam_r (name=0xbfa590aa "test", bufsize=1024) at
getent_test.cpp:36
#9 0x08048a8c in main (argc=2, argv=0xbfa58e04) at getent_test.cpp:86
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1970
------- 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] 8+ messages in thread* [Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes
2005-12-02 17:21 [Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes burnus at gmx dot de
2005-12-09 7:11 ` [Bug libc/1970] " kukuk at suse dot de
2005-12-09 11:53 ` burnus at gmx dot de
@ 2005-12-09 12:00 ` burnus at gmx dot de
2005-12-09 12:01 ` kukuk at suse dot de
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: burnus at gmx dot de @ 2005-12-09 12:00 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From burnus at gmx dot de 2005-12-09 12:00 -------
> [... working getgrnam_r ...]
(This of cause means working getgrnam(); this never failed for me.)
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1970
------- 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] 8+ messages in thread* [Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes
2005-12-02 17:21 [Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes burnus at gmx dot de
` (2 preceding siblings ...)
2005-12-09 12:00 ` burnus at gmx dot de
@ 2005-12-09 12:01 ` kukuk at suse dot de
2005-12-09 12:27 ` burnus at gmx dot de
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: kukuk at suse dot de @ 2005-12-09 12:01 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From kukuk at suse dot de 2005-12-09 12:01 -------
(In reply to comment #2)
> > _SC_GETGR_R_SIZE_MAX = 2048
> > mygetgrnam("testg", 1024) returned: ERANGE
>
> Hmm, _SC_GETGR_R_SIZE_MAX = 2048 is interesting.
It's because your test program you submitted contains "2*"
> I get the crash only with compat, with file I also get ERANGE.
So why did you wrote something complete different in the initial comment?
"(independent of group:files vs. group:compat)".
What is now the truth?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1970
------- 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] 8+ messages in thread* [Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes
2005-12-02 17:21 [Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes burnus at gmx dot de
` (3 preceding siblings ...)
2005-12-09 12:01 ` kukuk at suse dot de
@ 2005-12-09 12:27 ` burnus at gmx dot de
2005-12-30 20:52 ` drepper at redhat dot com
2006-04-23 19:47 ` drepper at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: burnus at gmx dot de @ 2005-12-09 12:27 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From burnus at gmx dot de 2005-12-09 12:27 -------
Created an attachment (id=789)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=789&action=view)
Test program, compile with g++ (uses "new")
I thought I attached the program here, but seemingly I didn't -- doing so now.
> > I get the crash only with compat, with file I also get ERANGE.
> So why did you wrote something complete different in the initial comment?
> "(independent of group:files vs. group:compat)".
Well, both is true:
Using getgrnam_r(name = "test", grp, buffer, bufsize=1024,result)
it only crashes with "group: compat". (Otherwise I get a ERANGE)
But using a buffer > 1024 it crashes with both group:compat and group:files
(stopping the nscd makes sense, otherwise the results can come from the cache,
I believe)
(gdb) run test
Starting program: /tmp/getent_test2 test
_SC_GETGR_R_SIZE_MAX = 1024
Call getgrnam_r(name = "test", grp, buffer, bufsize=2048,result)
Program received signal SIGSEGV, Segmentation fault.
0x4000b46a in fixup () from /lib/ld-linux.so.2
(gdb) bt
#0 0x4000b46a in fixup () from /lib/ld-linux.so.2
#1 0x4000b2c0 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#2 0x4001cd54 in internal_endent () from /lib/libnss_files.so.2
#3 0x4001d0a2 in _nss_files_getgrnam_r () from /lib/libnss_files.so.2
#4 0x401c7354 in getgrnam_r@@GLIBC_2.1.2 () from /lib/tls/libc.so.6
#5 0x080485b4 in mygetgrnam_r (name=0xbfa390a9 "test", bufsize=2048) at
getent_test2.cpp:15
#6 0x08048628 in main (argc=2, argv=0xbfa376e4) at getent_test2.cpp:23
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1970
------- 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] 8+ messages in thread* [Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes
2005-12-02 17:21 [Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes burnus at gmx dot de
` (4 preceding siblings ...)
2005-12-09 12:27 ` burnus at gmx dot de
@ 2005-12-30 20:52 ` drepper at redhat dot com
2006-04-23 19:47 ` drepper at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: drepper at redhat dot com @ 2005-12-30 20:52 UTC (permalink / raw)
To: glibc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
GCC host triplet|SUSE Linux 10.0 (i386) with |i386-linux
|kernel 2.6.14- |
|20051028140608-default |
http://sourceware.org/bugzilla/show_bug.cgi?id=1970
------- 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] 8+ messages in thread* [Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes
2005-12-02 17:21 [Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes burnus at gmx dot de
` (5 preceding siblings ...)
2005-12-30 20:52 ` drepper at redhat dot com
@ 2006-04-23 19:47 ` drepper at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: drepper at redhat dot com @ 2006-04-23 19:47 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2006-04-23 19:47 -------
There are at least two bugs in the program which have to make it crash:
- the test whether getgrnam_r returns something must be
if(result == NULL && res == 0) {
and not
if(&result == NULL && res == 0) {
&result is always != NULL
- you cannot call delete on 'result'. Only on 'buffer'.
I'm closing this bug. Reopen only after you can demonstrate with a C program
that there is indeed a problem. In this case you also have to provide a
description of the setup.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
http://sourceware.org/bugzilla/show_bug.cgi?id=1970
------- 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] 8+ messages in thread