0002434: Segmentation fault ls -l, ps - BusyBox Bug and Patch Tracking

(0007334)
kienvtran
05-01-08 09:15

Ran into the exact same problem on the same HW/SW platform. Attached is a fix in the form of an updated libbb/bb_pwd.c source file.

(0007344)
vda
05-01-08 23:58

/* bb_getpwuid, bb_getgrgid:
* bb_getXXXid(buf, bufsz, id) - copy user/group name or id
- * as a string to buf, return user/group name or NULL
- * bb_getXXXid(NULL, 0, id) - return user/group name or NULL
- * bb_getXXXid(NULL, -1, id) - return user/group name or exit
+ * as a string to buf, return user/group name
+ * bb_getXXXid(NULL, 0, id) - illegal
+ * bb_getXXXid(NULL, -1, id) - illegal
*/

id is broken now - coreutils/id.c:

puts((flags & JUST_USER) ? bb_getpwuid(NULL, -1, uid) : bb_getgrgid(NULL, -1, gid));

It would be better if instead of half-baked dirty fix you'd actually debugged the crash.

(0007354)
vda
05-02-08 00:19
edited on: 05-02-08 00:46

To debug it:

bb_pwd.c:

static char* bb_getug(char *buffer, int bufsize, char *idname, long id, char prefix)
{
        if (bufsize > 0) {
bb_error_msg("HERE1");
                assert(buffer != NULL);
                if (idname) {
bb_error_msg("HERE2");
                        return safe_strncpy(buffer, idname, bufsize);
                }
bb_error_msg("HERE3");
                snprintf(buffer, bufsize, "%ld", id);
        } else if (bufsize < 0 && !idname) {
bb_error_msg("HERE4");
                bb_error_msg_and_die("unknown %cid %ld", prefix, id);
        }
bb_error_msg("HERE5: return '%s'", idname);
        return idname;
}

Recompile, let it crash, and show the output.

(0007364)
fingar
05-02-08 05:25

result of debug

# ps
PID Uid VSZ Stat Command
ps: HERE1
ps: HERE2
Segmentation fault
#

(0007374)
vda
05-02-08 06:30
edited on: 05-02-08 06:32

Wow... can you replace lines

bb_error_msg("HERE2");
                        return safe_strncpy(buffer, idname, bufsize);

with

bb_error_msg("HERE2 buffer:%p idname:%p bufsize:%d", buffer, idname, bufsize);
bb_error_msg("HERE21 buffer:'%s'", buffer);
bb_error_msg("HERE22 idname:'%s'", idname);
                        safe_strncpy(buffer, idname, bufsize);
bb_error_msg("HERE23 returning '%s'", buffer);
                        return buffer;

(0007384)
kienvtran
05-02-08 07:49

When I inserted debug statements like vda suggested, without modifying the code, the bug DISAPPEARED. In that case the outputs of "ls -l" and "ps" were useless, as they were interspersed with debug statements.

Are there regression tests that I could run to ensure that I don't break anything else? Sorry about "id" breaking, I am kind of new at this.

(0007394)
fingar
05-02-08 08:49

replaced the code with the extra debug messages as vda suggested. output is now
# ps
  PID Uid VSZ Stat Command
ps: HERE1
ps: HERE2 buffer:0x944a4 idname 0x94510 bufsize 12
ps: HERE21 buffer:''
ps: HERE22 idname:'root'
ps: HERE23 returning 'root'
    1 root 3000 S init
    2 root SWN [ksoftirqd/0]
    3 root SW< [events/0]
    4 root SW< [khelper]
    5 root SW< [kthread]
   40 root SW< [kblockd/0]
   44 root SW< [khubd]
   46 root SW< [kseriod]
   59 root SW [pdflush]
   60 root SW [pdflush]
   61 root SW< [kswapd0]
   62 root SW< [aio/0]
   64 root SW< [jfsIO]
   65 root SW< [jfsCommit]
   66 root SW< [jfsSync]
  675 root SW [mtdblockd]
  712 root SWN [jffs2_gcd_mtd1]
  720 root 3004 S /sbin/syslogd -O /var/log/messages
  722 root 3004 S /sbin/klogd
  728 root 3008 S /bin/sh
  733 root 3008 R ps
#

It works now. Is this a toolchain problem. If I remove the debug messages is it likely other things will be broken?

(0007404)
fingar
05-02-08 09:39

Ihave done some further tests.
I returned bb_pwd.c to the original version & modified safe_strncpy.c to return the buffer instead of the return of strncpy.
This also produced a segmentation error.
So the only way I seem to get it to work is to use the original safe_strncpy.c and the modified bb_pwd.c which returns buffer instead of the return of safe_strncpy().

I guess this is looking like a toolchain problem as I can't see why the original bb_pwd.c shouldn't work.

(0007424)
vda
05-03-08 01:38

What are the versions of ld and gcc? Post full output of gcc -v and ld -v.

(0007444)
kienvtran
05-05-08 16:38

$ $CROSS_COMPILE"gcc" -v
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: /scratch/paul/lite/linux/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-symvers=gnu --enable-__cxa_atexit --with-pkgversion=CodeSourcery Sourcery G++ Lite 2007q3-51 --with-bugurl=https://support.codesourcery.com/GNUToolchain/ [^] --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/paul/lite/linux/install/arm-none-linux-gnueabi/libc --enable-poison-system-directories --with-build-time-tools=/scratch/paul/lite/linux/install/arm-none-linux-gnueabi/bin --with-build-time-tools=/scratch/paul/lite/linux/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)

$ $CROSS_COMPILE"ld" -v
GNU ld (CodeSourcery Sourcery G++ Lite 2007q3-51) 2.18.50.20070820

(0007454)
fingar
05-06-08 03:21
edited on: 05-06-08 07:14

It seems this is a known bug with this toolchain see:
Re: [arm-gnu] 2007q3 generates bad code for busybox bb_getug()

    * To: arm-gnu@xxxxxxxxxxxxxxxx
    * Subject: Re: [arm-gnu] 2007q3 generates bad code for busybox bb_getug()
    * From: Paul Brook <paul@xxxxxxxxxxxxxxxx>
    * Date: Wed, 9 Jan 2008 18:11:54 +0000

> just a heads up: I compiled busybox-1.7.2 with the arm-2007q3-51-linux
> EABI toolchain, for default arch (armv5) with -Os. A few of the

This is a known issue with the current release. You can workaround the bug by
not using -Os, or by adding -fno-optimize-sibling-calls.

The problem will be fixed in the next release.

Paul

I guess I can try their fix or get the latest compiler release

I just got the latest release and the problem is still there.

I changed the C flags from Os to O2. All is well. Also gzip didn't work properly before and is also fixed.

Issue History
Date Modified	Username	Field	Change
03-06-08 02:19	fingar	New Issue
03-06-08 02:19	fingar	Status	new => assigned
03-06-08 02:19	fingar	Assigned To	=> BusyBox
05-01-08 09:15	kienvtran	Note Added: 0007334
05-01-08 09:15	kienvtran	File Added: bb_pwd.c
05-01-08 23:58	vda	Note Added: 0007344
05-02-08 00:19	vda	Note Added: 0007354
05-02-08 00:46	vda	Note Edited: 0007354
05-02-08 05:25	fingar	Note Added: 0007364
05-02-08 06:30	vda	Note Added: 0007374
05-02-08 06:32	vda	Note Edited: 0007374
05-02-08 07:49	kienvtran	Note Added: 0007384
05-02-08 08:49	fingar	Note Added: 0007394
05-02-08 09:39	fingar	Note Added: 0007404
05-03-08 01:38	vda	Note Added: 0007424
05-05-08 16:38	kienvtran	Note Added: 0007444
05-06-08 03:21	fingar	Note Added: 0007454
05-06-08 07:14	fingar	Note Edited: 0007454
05-06-08 08:52	bernhardf	Status	assigned => closed
05-06-08 08:52	bernhardf	Resolution	open => no change required

Notes
(0007334) kienvtran 05-01-08 09:15	Ran into the exact same problem on the same HW/SW platform. Attached is a fix in the form of an updated libbb/bb_pwd.c source file.

(0007344) vda 05-01-08 23:58	/* bb_getpwuid, bb_getgrgid: * bb_getXXXid(buf, bufsz, id) - copy user/group name or id - * as a string to buf, return user/group name or NULL - * bb_getXXXid(NULL, 0, id) - return user/group name or NULL - * bb_getXXXid(NULL, -1, id) - return user/group name or exit + * as a string to buf, return user/group name + * bb_getXXXid(NULL, 0, id) - illegal + * bb_getXXXid(NULL, -1, id) - illegal */ id is broken now - coreutils/id.c: puts((flags & JUST_USER) ? bb_getpwuid(NULL, -1, uid) : bb_getgrgid(NULL, -1, gid)); It would be better if instead of half-baked dirty fix you'd actually debugged the crash.

(0007354) vda 05-02-08 00:19 edited on: 05-02-08 00:46	To debug it: bb_pwd.c: static char* bb_getug(char buffer, int bufsize, char idname, long id, char prefix) { if (bufsize > 0) { bb_error_msg("HERE1"); assert(buffer != NULL); if (idname) { bb_error_msg("HERE2"); return safe_strncpy(buffer, idname, bufsize); } bb_error_msg("HERE3"); snprintf(buffer, bufsize, "%ld", id); } else if (bufsize < 0 && !idname) { bb_error_msg("HERE4"); bb_error_msg_and_die("unknown %cid %ld", prefix, id); } bb_error_msg("HERE5: return '%s'", idname); return idname; } Recompile, let it crash, and show the output.

(0007364) fingar 05-02-08 05:25	result of debug # ps PID Uid VSZ Stat Command ps: HERE1 ps: HERE2 Segmentation fault #

(0007374) vda 05-02-08 06:30 edited on: 05-02-08 06:32	Wow... can you replace lines bb_error_msg("HERE2"); return safe_strncpy(buffer, idname, bufsize); with bb_error_msg("HERE2 buffer:%p idname:%p bufsize:%d", buffer, idname, bufsize); bb_error_msg("HERE21 buffer:'%s'", buffer); bb_error_msg("HERE22 idname:'%s'", idname); safe_strncpy(buffer, idname, bufsize); bb_error_msg("HERE23 returning '%s'", buffer); return buffer;

(0007384) kienvtran 05-02-08 07:49	When I inserted debug statements like vda suggested, without modifying the code, the bug DISAPPEARED. In that case the outputs of "ls -l" and "ps" were useless, as they were interspersed with debug statements. Are there regression tests that I could run to ensure that I don't break anything else? Sorry about "id" breaking, I am kind of new at this.

(0007394) fingar 05-02-08 08:49	replaced the code with the extra debug messages as vda suggested. output is now # ps PID Uid VSZ Stat Command ps: HERE1 ps: HERE2 buffer:0x944a4 idname 0x94510 bufsize 12 ps: HERE21 buffer:'' ps: HERE22 idname:'root' ps: HERE23 returning 'root' 1 root 3000 S init 2 root SWN [ksoftirqd/0] 3 root SW< [events/0] 4 root SW< [khelper] 5 root SW< [kthread] 40 root SW< [kblockd/0] 44 root SW< [khubd] 46 root SW< [kseriod] 59 root SW [pdflush] 60 root SW [pdflush] 61 root SW< [kswapd0] 62 root SW< [aio/0] 64 root SW< [jfsIO] 65 root SW< [jfsCommit] 66 root SW< [jfsSync] 675 root SW [mtdblockd] 712 root SWN [jffs2_gcd_mtd1] 720 root 3004 S /sbin/syslogd -O /var/log/messages 722 root 3004 S /sbin/klogd 728 root 3008 S /bin/sh 733 root 3008 R ps # It works now. Is this a toolchain problem. If I remove the debug messages is it likely other things will be broken?

(0007404) fingar 05-02-08 09:39	Ihave done some further tests. I returned bb_pwd.c to the original version & modified safe_strncpy.c to return the buffer instead of the return of strncpy. This also produced a segmentation error. So the only way I seem to get it to work is to use the original safe_strncpy.c and the modified bb_pwd.c which returns buffer instead of the return of safe_strncpy(). I guess this is looking like a toolchain problem as I can't see why the original bb_pwd.c shouldn't work.

(0007424) vda 05-03-08 01:38	What are the versions of ld and gcc? Post full output of gcc -v and ld -v.

(0007444) kienvtran 05-05-08 16:38	$ $CROSS_COMPILE"gcc" -v Using built-in specs. Target: arm-none-linux-gnueabi Configured with: /scratch/paul/lite/linux/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-symvers=gnu --enable-__cxa_atexit --with-pkgversion=CodeSourcery Sourcery G++ Lite 2007q3-51 --with-bugurl=https://support.codesourcery.com/GNUToolchain/ [^] --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/paul/lite/linux/install/arm-none-linux-gnueabi/libc --enable-poison-system-directories --with-build-time-tools=/scratch/paul/lite/linux/install/arm-none-linux-gnueabi/bin --with-build-time-tools=/scratch/paul/lite/linux/install/arm-none-linux-gnueabi/bin Thread model: posix gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51) $ $CROSS_COMPILE"ld" -v GNU ld (CodeSourcery Sourcery G++ Lite 2007q3-51) 2.18.50.20070820

(0007454) fingar 05-06-08 03:21 edited on: 05-06-08 07:14	It seems this is a known bug with this toolchain see: Re: [arm-gnu] 2007q3 generates bad code for busybox bb_getug() * To: arm-gnu@xxxxxxxxxxxxxxxx * Subject: Re: [arm-gnu] 2007q3 generates bad code for busybox bb_getug() * From: Paul Brook <paul@xxxxxxxxxxxxxxxx> * Date: Wed, 9 Jan 2008 18:11:54 +0000 > just a heads up: I compiled busybox-1.7.2 with the arm-2007q3-51-linux > EABI toolchain, for default arch (armv5) with -Os. A few of the This is a known issue with the current release. You can workaround the bug by not using -Os, or by adding -fno-optimize-sibling-calls. The problem will be fixed in the next release. Paul I guess I can try their fix or get the latest compiler release I just got the latest release and the problem is still there. I changed the C flags from Os to O2. All is well. Also gzip didn't work properly before and is also fixed.

Relationships