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

Reply via email to