Hi,

Sorry for the delay - I was doublechecking this on Ubuntu 12.04 and
13.04 - in both cases I was able to reproduce it. Also, I realized I
have missed out one thing (probably assumed it was obvious - which it
is not - and maybe this is why you could not reproduce it):

The code I sent uses /tmp to create .so files and later on unpack the
libraries - /tmp has to be aufs, or you can change the code to write
to ./dlopenXXXXXX - and run it from a directory using aufs mount.
(I always ran it in a chroot since that is how I reproduced the issue
in the first place)

The code I used to check the issue is exactly the one I sent
previously - and failed in the same way:

/ # ./test2
Test_FuncA: OK, 0xb73f44fc
Test_FuncB: /tmp/dlopenMqPcJ3: undefined symbol: Test_FuncB

I am going to use Ubuntu 13.04 since it is a VM and I can break it
(and the 12.04 I used so far is not so I'd rather not try installing
aufs there).

As for Linux kernel sources - the source .deb can be downloaded from
http://us.archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-source-3.8.0_3.8.0-31.46_all.deb
- it contains the .tar.gz with sources. I can also upload the .tar.gz
somewhere if that is more convenient.

Here are the details from Ubuntu 13.04:

Version from dmesg:
[  160.316469] aufs 3.x-rcN-20121112

Mount command used:
mount none /mnt/aufs-test -t aufs -o dirs=/mnt/aufs-tmp:/rootfs

I am also attaching a .tar.gz with proc/mounts, sys/fs/aufs and sys/module/aufs

I will also try to compile latest aufs and see if it changes anything.

2013/10/9  <sf...@users.sourceforge.net>:
>
> Wojciech Kocjan:
>> As for read/write differences - I added checking for write() and
>> read() result and I did not see any differences. I am wondering,
>> however, if it is possible that the created .so was smaller and this
>> is why it was working fine for you. I am attaching an updated code
>> that creates much larger .so files and more exported functions in case
>> this was why it was working fine for you. Maybe that will allow
>> reproducing it on your side?
>
> No, it didn't happen on my test machine. I tried several times.
> Here is a minor change of your program. Won't you test this and see an
> error happens?
>
> diff --git a/test/wojciech2.c b/test/wojciech2.c
> index d5509bc..114a788 100644
> --- a/test/wojciech2.c
> +++ b/test/wojciech2.c
> @@ -7,6 +7,7 @@
>  #include <sys/stat.h>
>  #include <unistd.h>
>  #include <fcntl.h>
> +#include <assert.h>
>
>  void test_dlopen(char *funcname, int dlsize, char *dldata)
>  {
> @@ -14,6 +15,7 @@ void test_dlopen(char *funcname, int dlsize, char *dldata)
>      void *dl;
>      int fd;
>      int s2;
> +    int err;
>
>      strcpy(filebuf, "/tmp/dlopenXXXXXX");
>      mktemp(filebuf);
> @@ -23,7 +25,8 @@ void test_dlopen(char *funcname, int dlsize, char *dldata)
>         s2 = write(fd, dldata, dlsize);
>         if (s2 != dlsize)
>             printf("Unable to write data - %08x vs %08x", dlsize, s2);
> -       close(fd);
> +       err = close(fd);
> +       assert(!err);
>         dl = dlopen(filebuf, RTLD_NOW | RTLD_GLOBAL);
>         if (dl != NULL)
>         {
> @@ -63,8 +66,9 @@ char *build_so(int *sizePtr, char *funcname)
>      int s1, s2;
>      char *result = NULL;
>      struct stat statbuf;
> -    void *dl;
>      int fd;
> +    ssize_t ssz, ssz2;
> +    int err;
>
>      strcpy(filebuf, "/tmp/dlopenXXXXXX");
>      mktemp(filebuf);
> @@ -86,19 +90,26 @@ char *build_so(int *sizePtr, char *funcname)
>      fd = open(filebufc, O_CREAT|O_WRONLY|O_TRUNC, 0644);
>      if (fd >= 0)
>      {
> -       write(fd, buf, strlen(buf));
> -       close(fd);
> +       ssz2 = strlen(buf);
> +       ssz = write(fd, buf, ssz2);
> +       assert(ssz == ssz2);
> +       err = close(fd);
> +       assert(!err);
>         sprintf(buf, "gcc -shared -o \"%s\" \"%s\"", filebuf, filebufc);
> -       system(buf);
> +       err = system(buf);
> +       assert(WIFEXITED(err));
> +       assert(!WEXITSTATUS(err));
>      }
>
>      fd = open(filebuf, O_RDONLY);
>      if (fd >= 0)
>      {
> -       stat(filebuf, &statbuf);
> +       err = stat(filebuf, &statbuf);
> +       assert(!err);
>         s1 = statbuf.st_size;
>         *sizePtr = s1;
>         result = malloc(s1);
> +       assert(result);
>         s2 = read(fd, result, s1);
>         if (s1 != s2) {
>             printf("UNABLE TO READ SO: %08x vs %08x\n", s1, s2);
> @@ -109,7 +120,7 @@ char *build_so(int *sizePtr, char *funcname)
>  }
>
>
> -main()
> +int main(int argc, char *argv[])
>  {
>      char *buf1, *buf2;
>      int bufSize1, bufSize2;
> @@ -118,5 +129,6 @@ main()
>
>      test_dlopen("Test_FuncA", bufSize1, buf1);
>      test_dlopen("Test_FuncB", bufSize2, buf2);
> -}
>
> +    return 0;
> +}
>
> And here is necessary info written in aufs README file.
> ----------------------------------------
> When you have any problems or strange behaviour in aufs, please let me
> know with:
> - /proc/mounts (instead of the output of mount(8))
> - /sys/module/aufs/*
> - /sys/fs/aufs/* (if you have them)
> - /debug/aufs/* (if you have them)
> - linux kernel version
>   if your kernel is not plain, for example modified by distributor,
>   the url where i can download its source is necessary too.
> - aufs version which was printed at loading the module or booting the
>   system, instead of the date you downloaded.
> - configuration (define/undefine CONFIG_AUFS_xxx)
> - kernel configuration or /proc/config.gz (if you have it)
> - behaviour which you think to be incorrect
> - actual operation, reproducible one is better
> - mailto: aufs-users at lists.sourceforge.net
>
> Usually, I don't watch the Public Areas(Bugs, Support Requests, Patches,
> and Feature Requests) on SourceForge. Please join and write to
> aufs-users ML.
> ----------------------------------------
>
>
> J. R. Okajima
>

Attachment: os_data.tar.gz
Description: GNU Zip compressed data

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk

Reply via email to