On 1/15/15 4:47 , Alexander Pyhalov via illumos-discuss wrote:
> Hello.
> I look at strange issue with df test from coreutils testsuite.
> The test is simple:
> $ cat 1.c
> #include <stdio.h>
> #include <errno.h>
> #ifdef __sun
> #include <sys/mntent.h>
> #else
> #include <mntent.h>
> #endif
>
> struct mntent *getmntent (FILE *fp)
> {
> errno = ENOENT;
> return NULL;
> }
>
> $ gcc -fPIC -shared 1.c -o 1.so
> $ LD_PRELOAD 1.so /usr/gnu/bin/df
>
> On Linux df prints
> df: cannot read table of mounted file systems: No such file or directory
>
> But on OI I receive see strange core dump (in libc ?):
> Program terminated with signal 11, Segmentation fault.
> #0 0xfee76214 in strstr () from /lib/libc.so.1
>
> So, it seems it code even doesn't reach df's main. How can it be? Is it
> runtime linker fault? I just don't remember seeing such backtrace...
>
So, the getmntent() signatures on illumos and GNU/Linux are quite
different. I would presume that df normally handles this difference in
its source code; however, it's not surprising that this test would cause
things to fail.
On illumos it's actually:
int getmntent(FILE *fp, struct mnttab *mp);
Which is an SVR4-ism. So by returning NULL, you actually indicate
success meaning that the data has been filled into the struct mnttab. If
you look at the gnulib() source for the read_file_system_list() function
and make it through the series of #ifdefs, you'll see for SVR4, they
properly use this form of the function, and therefore is going ahead and
dereferencing the stack allocat struct mnttab structure.
In this case, you'll have to rephrase the test into an SVR4-compatible form.
Robert
Robert
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
