StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POWhy would linking against the FastCGI library cause a segfault?
text
Body
copied!<p>I have a program that is using a library called "wjelement", whenever I try to use this library with FastCGI I get a segfault. I have made a simplified test case below. If I compile the code without fcgi_stdio.h and do not link against the library, the code works fine, if I add the fastcgi header and link against it I get a segfault, even if I don't use any fast cgi calls.</p> <p>In My FastCGI code the opposite is also true, if I remove the WJelement code the rest of the program works fine.</p> <p>I'm not sure if I need to blame my program, the FastCGI Library, or the WJElement library...</p> <pre><code>#include <stdio.h> #include <fcgi_stdio.h> #include <wjreader.h> int main (int argc, char *argv[]) { FILE *my_schema_file; my_schema_file = fopen("test_schema.json", "rb"); if (my_schema_file == NULL) { printf("Failed to open test schema file\n"); return 1; } else { printf("Opened test schema file\n"); } WJReader my_schema_reader; my_schema_reader = WJROpenFILEDocument(my_schema_file, NULL, 0); if (my_schema_reader == NULL) { printf("Failed to open test schema reader\n"); return 1; } else { printf("Opened test schema reader\n"); } return 0; } </code></pre> <p>GDB Backtrace:</p> <pre><code>Program received signal SIGSEGV, Segmentation fault. 0x0000003e19e6c85f in __GI__IO_fread (buf=0x6023c4, size=1, count=2731, fp=0x602250) at iofread.c:41 41 _IO_acquire_lock (fp); (gdb) backtrace #0 0x0000003e19e6c85f in __GI__IO_fread (buf=0x6023c4, size=1, count=2731, fp=0x602250) at iofread.c:41 #1 0x00007ffff7dde5d9 in WJRFileCallback () from /lib/libwjreader.so.0 #2 0x00007ffff7dde037 in WJRFillBuffer () from /lib/libwjreader.so.0 #3 0x00007ffff7dde4e9 in _WJROpenDocument () from /lib/libwjreader.so.0 #4 0x000000000040081f in main (argc=1, argv=0x7fffffffdeb8) at test.c:20 </code></pre>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload