[Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Wolfgang Glas]

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 
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
1230hpgspdffile.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.
0x07ff7fc52806 in ?? ()
(gdb) bt
#0  0x07ff7fc52806 in ?? ()
#1  0x07ff7fc4a949 in ?? ()
#2  0x0003 in ?? ()
#3  0x0003 in ?? ()
#4  0x0003 in ?? ()
#5  0x0033d627 in ?? ()
#6  0x 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

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Wolfgang Glas]

Kai Tietz schrieb:
> 2009/3/15 Wolfgang Glas :
>> 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 
>> 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
>> 1230hpgspdffile.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.
>> 0x07ff7fc52806 in ?? ()
>> (gdb) bt
>> #0  0x07ff7fc52806 in ?? ()
>> #1  0x07ff7fc4a949 in ?? ()
>> #2  0x0003 in ?? ()
>> #3  0x0003 in ?? ()
>> #4  0x0003 in ?? ()
>> #5  0x0033d627 in ?? ()
>> #6  0x 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
>>
> 
> By trying to reduce this test case I stumble over the assembly produced
>  leaq30(%rbx), %rax
>  andq$-16, %rax
>  call___chkstk
> 
> so, if %rbx is zero (len == 0) this happens what you are describing.
> that tail_data is just 16 bytes away from file_len. So possibly you
> should check the result of hpgs_istream_tell(pdf->is,&file_len), if
> file_len is not equal to zero. If it is, all points to an alias issue.

Well, if I print the content of len in my debugging session, I get:

Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230
1230hpgspdffile.c: No such file or directory.
in hpgspdffile.c
(gdb) print len
$1 = 2048
(gdb) print &len
$2 = (size_

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Kai Tietz]

2009/3/15 Wolfgang Glas :
> 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 
> 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.
> 0x07ff7fc52806 in ?? ()
> (gdb) bt
> #0  0x07ff7fc52806 in ?? ()
> #1  0x07ff7fc4a949 in ?? ()
> #2  0x0003 in ?? ()
> #3  0x0003 in ?? ()
> #4  0x0003 in ?? ()
> #5  0x0033d627 in ?? ()
> #6  0x 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
>

By trying to reduce this test case I stumble over the assembly produced
 leaq30(%rbx), %rax
 andq$-16, %rax
 call___chkstk

so, if %rbx is zero (len == 0) this happens what you are describing.
that tail_data is just 16 bytes away from file_len. So possibly you
should check the result of hpgs_istream_tell(pdf->is,&file_len), if
file_len is not equal to zero. If it is, all points to an alias issue.

Cheers,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

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

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Kai Tietz]

2009/3/15 Wolfgang Glas :
> Kai Tietz schrieb:
>> 2009/3/15 Wolfgang Glas :
>>> 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 
>>> 
>>> 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.
>>> 0x07ff7fc52806 in ?? ()
>>> (gdb) bt
>>> #0  0x07ff7fc52806 in ?? ()
>>> #1  0x07ff7fc4a949 in ?? ()
>>> #2  0x0003 in ?? ()
>>> #3  0x0003 in ?? ()
>>> #4  0x0003 in ?? ()
>>> #5  0x0033d627 in ?? ()
>>> #6  0x 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
>>>
>>
>> By trying to reduce this test case I stumble over the assembly produced
>>  leaq    30(%rbx), %rax
>>  andq    $-16, %rax
>>  call    ___chkstk
>>
>> so, if %rbx is zero (len == 0) this happens what you are describing.
>> that tail_data is just 16 bytes away from file_len. So possibly you
>> should check the result of hpgs_istream_tell(pdf->is,&file_len), if
>> file_len is not equal to zero. If it is, all points to an alias issue.
>
> Well, if I print the content of len in my debugging session, I get:
>
> Breakpoint 1, hpgs_pdf_file_read_xref (pd

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Shaun Barlow]

Hi,

> Ok, I found the issue. Your application calls __chkstk from kernel32,
> which is pretty false. Because the MS variant just probes the stack,
> but does not allocate it as the cygwin variant. There are two possible
> ways to solve this, a) Remove the export from kernel32.def in lib64,
> or rename the method in gcc/config/i386 defined in cygwin.asm and
> referenced in i386.md

Thank you very much to Wolfgang for making the testcase, and Kai for
finding the problem :)
Applying Kai's solution a) Remove the export from kernel32.def in
lib64, to a local checkout
of the mingw-w64 crt has gotten rid of the segfaults I was
experiencing in my program

In my opinion, solution a) would be the correct course because it
matches the behaviour of both
the mingw project's export library and Microsoft own export library
(referencing __chkstk in either
and then linking to kernel32 gives an unresolved symbol). Its naming
(double underscore prefix), would
also seem to indicate that it is not intended for outside use.

It is obviously Kai's decision which route to take.

Thanks and best regards,
Shaun

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

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Kai Tietz]

2009/3/15 Shaun Barlow :
> Hi,
>
>> Ok, I found the issue. Your application calls __chkstk from kernel32,
>> which is pretty false. Because the MS variant just probes the stack,
>> but does not allocate it as the cygwin variant. There are two possible
>> ways to solve this, a) Remove the export from kernel32.def in lib64,
>> or rename the method in gcc/config/i386 defined in cygwin.asm and
>> referenced in i386.md
>
> Thank you very much to Wolfgang for making the testcase, and Kai for
> finding the problem :)
> Applying Kai's solution a) Remove the export from kernel32.def in
> lib64, to a local checkout
> of the mingw-w64 crt has gotten rid of the segfaults I was
> experiencing in my program
>
> In my opinion, solution a) would be the correct course because it
> matches the behaviour of both
> the mingw project's export library and Microsoft own export library
> (referencing __chkstk in either
> and then linking to kernel32 gives an unresolved symbol). Its naming
> (double underscore prefix), would
> also seem to indicate that it is not intended for outside use.
>
> It is obviously Kai's decision which route to take.
>
> Thanks and best regards,
> Shaun
>

Yes, this issue is a bit annoying and is ported from mingw32. I
disabled temporary the export symbol __chkstk in ntdll.def,
kernel32.def, and ntoskernl.def. So always the variant of gcc is used
and those kind of errors a prevented. But this means of course that vc
generated libraries, which are using __chkstk will fail (as the do on
32-bits).
I want to provide a change in 4.5 gcc to avoid this issue completely
and allow the co-existance of gcc's and vc's stack checking routine
for 64-bit and 32-bit by renaming the gcc's variant to __gnu_chkstk.

Fix is on mingw-w64 trunk rev.678.

Cheers,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

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

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[NightStrike]

On Sun, Mar 15, 2009 at 9:41 AM, Kai Tietz  wrote:
> Fix is on mingw-w64 trunk rev.678.

Thank you very much to Kai, Wolfgang, and Shaun!

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