Hey everyone,
I'm using some 3rd party code that depends on zlib. In particular, it uses gzread() in order to read a file. Unfortunately, the corresponding piece of code causes a segfault in ld.lib.so.
I narrowed this down to the following minimum example:
gzFile gzfile_components = gzopen("test.txt", "rb"); unsigned char buffer[1024*1024]; gzread(gzfile_components, buffer, sizeof(buffer));
As you can see, the buffer is quite large but this the actual (and reasonable) value used in the 3rd party code. As soon as I reduce the size to e.g. 4096, the segfault is gone.
The file I used has a size of 293 bytes. I'm using base-linux. I also remember using this code successfully on a different computer with an older version of Genode (14.03).
Any ideas/comments on this?
Hi Johannes,
On 10/30/2014 08:01 PM, Johannes Schlatow wrote:
Hey everyone,
I'm using some 3rd party code that depends on zlib. In particular, it uses gzread() in order to read a file. Unfortunately, the corresponding piece of code causes a segfault in ld.lib.so.
I narrowed this down to the following minimum example:
gzFile gzfile_components = gzopen("test.txt", "rb"); unsigned char buffer[1024*1024]; gzread(gzfile_components, buffer, sizeof(buffer));
As you can see, the buffer is quite large but this the actual (and reasonable) value used in the 3rd party code. As soon as I reduce the size to e.g. 4096, the segfault is gone.
The file I used has a size of 293 bytes. I'm using base-linux. I also remember using this code successfully on a different computer with an older version of Genode (14.03).
Any ideas/comments on this?
Are you using Genode's staging or master branch? I am asking because we just switched to a new ld.lib.so implementation on staging. Nevertheless, in order to help I would need some way to reproduce your error, for example a run script triggering the error or source code would do, I cannot tell the problem from your code snippet above.
Cheers,
Sebastian
Hey,
You put that quite large buffer on stack. Does the page fault occur in the stack area 0x40000000..0x50000000? Our stacks have a limited size and do not grow automatically.
Greets Christian
On October 30, 2014 8:01:05 PM CET, Johannes Schlatow <schlatow@...238...> wrote:
Hey everyone,
I'm using some 3rd party code that depends on zlib. In particular, it uses gzread() in order to read a file. Unfortunately, the corresponding piece of code causes a segfault in ld.lib.so.
I narrowed this down to the following minimum example:
gzFile gzfile_components = gzopen("test.txt", "rb"); unsigned char buffer[1024*1024]; gzread(gzfile_components, buffer, sizeof(buffer));
As you can see, the buffer is quite large but this the actual (and reasonable) value used in the 3rd party code. As soon as I reduce the size to e.g. 4096, the segfault is gone.
The file I used has a size of 293 bytes. I'm using base-linux. I also remember using this code successfully on a different computer with an older version of Genode (14.03).
Any ideas/comments on this?
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Christian,
You put that quite large buffer on stack. Does the page fault occur in the stack area 0x40000000..0x50000000? Our stacks have a limited size and do not grow automatically.
That is what I suspect too. After some further testing, I found out that the segfault occurs for buffer sizes above 12kB, which I suppose is the default stack size in Genode.
Assuming that I cannot easily move the buffer to the heap, I'll have to extend the stack. I suppose the way to go is to create a new Genode::Thread for which I can allocate a sufficiently large stack, right?
By the way, you can find the code on github: https://github.com/ValiValpas/genode/commit/96ef7acec75c87865b1021d77645a349...
I'm NOT using the staging branch.
Cheers Johannes
On Fri, 31 Oct 2014 08:30:06 +0100 Christian Helmuth <christian.helmuth@...1...> wrote:
Hey,
You put that quite large buffer on stack. Does the page fault occur in the stack area 0x40000000..0x50000000? Our stacks have a limited size and do not grow automatically.
Greets Christian
On October 30, 2014 8:01:05 PM CET, Johannes Schlatow <schlatow@...238...> wrote:
Hey everyone,
I'm using some 3rd party code that depends on zlib. In particular, it uses gzread() in order to read a file. Unfortunately, the corresponding piece of code causes a segfault in ld.lib.so.
I narrowed this down to the following minimum example:
gzFile gzfile_components = gzopen("test.txt", "rb"); unsigned char buffer[1024*1024]; gzread(gzfile_components, buffer, sizeof(buffer));
As you can see, the buffer is quite large but this the actual (and reasonable) value used in the 3rd party code. As soon as I reduce the size to e.g. 4096, the segfault is gone.
The file I used has a size of 293 bytes. I'm using base-linux. I also remember using this code successfully on a different computer with an older version of Genode (14.03).
Any ideas/comments on this?
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Johannes,
On 10/31/2014 10:36 AM, Johannes Schlatow wrote:
Christian,
You put that quite large buffer on stack. Does the page fault occur in the stack area 0x40000000..0x50000000? Our stacks have a limited size and do not grow automatically.
That is what I suspect too. After some further testing, I found out that the segfault occurs for buffer sizes above 12kB, which I suppose is the default stack size in Genode.
Assuming that I cannot easily move the buffer to the heap, I'll have to extend the stack. I suppose the way to go is to create a new Genode::Thread for which I can allocate a sufficiently large stack, right?
By the way, you can find the code on github: https://github.com/ValiValpas/genode/commit/96ef7acec75c87865b1021d77645a349...
I'm NOT using the staging branch.
Thanks for the link, I have tested it on Linux. As Christian suggested it is a page fault because of a stack overrun in the main thread. The main thread has only 64KB of stack. The way I see it you have three options to allocate the buffer (not counting creating a new thread).
1. Call Genode::env()->heap()->alloc (Assuming you can use the heap) 2. Use an attached dataspace (see: repos/os/include/os/attached_dataspace.h) in order to request some memory from your parent. 3. If the above two are not possible in you scenario, I would move the buffer into the bss segment of your binary by making it a global variable.
Sebastian
-
Christian Helmuth -
Johannes Schlatow -
Sebastian Sumpf