Hi all, I've been trying very hard to reduce my alloca() problems and at got stuck with every attempt to isolate the problem.
Finally I linked a mildly complex C-program, which crashed before using a handcrafted Makefile and luckily I found out, that the program crashes, when I add a bunch Window's system libraries to the linker command line. (A practice I cowardly copied from another project years ago...) I've uploaded a self-contained (but not small) testcase to our weebserver under http://www.ev-i.at/tmp/mingw_hpgspdf_test.tar.gz The makefile generates two executables: One linked just with the self-generated DLLs and one linked with a long list of windows system libraries. The executable linked with the windows libraries is called hpgspdffile-read-fail.exe and has a different size than the executable hpgspdffile-read.exe linked with just the self-generated libraries. Besides, it has the same runtime dependencies and however it *does* crash right after alloca(), while the other one survives flawlessly. The program reads a PDF-file, interprets it's internal structure and re-serializes the file afterwards. (Should work with any normal PDF-file). This is my debug-session: ************************************** H:\wglas\CC\mingw_hpgspdf_test\bin64>gdb-w64 .\hpgspdffile-read-fail.exe GNU gdb 6.7.50.20080109-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-mingw32"... warning: A handler for the OS ABI "Cygwin" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings. (gdb) break hpgspdffile.c:1230 Breakpoint 1 at 0x40eead: file hpgspdffile.c, line 1230. (gdb) r H:\wglas\doc\hp\bpl13205.pdf x.pdf Starting program: H:\wglas\CC\mingw_hpgspdf_test\bin64/.\hpgspdffile-read-fail.e xe H:\wglas\doc\hp\bpl13205.pdf x.pdf len=28. value=C:\Program Files (x86)\cdes. prefix=C:\Program Files (x86)\cdes. Opening file H:\wglas\doc\hp\bpl13205.pdf. Reading file H:\wglas\doc\hp\bpl13205.pdf. Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230 1230 hpgspdffile.c: No such file or directory. in hpgspdffile.c (gdb) print tail_data $1 = 0x22fda0 "" (gdb) print &len $2 = (size_t *) 0x22fdb0 (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x000007ff7fc52806 in ?? () (gdb) bt #0 0x000007ff7fc52806 in ?? () #1 0x000007ff7fc4a949 in ?? () #2 0x0000000000000003 in ?? () #3 0x0000000000000003 in ?? () #4 0x0000000000000003 in ?? () #5 0x000000000033d627 in ?? () #6 0x0000000000000000 in ?? () (gdb) q The program is running. Exit anyway? (y or n) y H:\wglas\CC\mingw_hpgspdf_test\bin64> ************************************** Explanation: tail_data is a char-array of size 2048, which has been allocated through alloca(), 'len' is a local variable. The problem her is, that alloca() places tail_data 16 bytes before len, which is far less than the required 2048 bytes... Hopefully, this will bring us one step further in resolving this curious problem. Regards, Wolfgang ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public