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


------------------------------------------------------------------------------
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