Re: [Mingw-w64-public] Weird crash when using Ruben's gcc4.6 stdthread package rebuilt gdb with -Os debug some program

2011-10-08 Thread xunxun 
I cross build the windows gcc4.6.2 on linux, the issue also existed.
I don't know whether the issue is only targeted windows?
I report it to gcc bugzilla :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50664

On Fri, Sep 30, 2011 at 7:50 PM, xunxun xunxun1...@gmail.com wrote:

  On 2011/9/30 7:02, xunxun wrote:

 Ruben, can you try to build gdb with -Os using your edition, test it
 debugging?

 Kai, what changes gcc's -Os from gcc4.6.1 to now, because I use gcc4.6.1
 release to build well.


 Thanks.

 --
 Best Regards,
 xunxun




-- 
Best Regards,
xunxun
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Weird crash when using Ruben's gcc4.6 stdthread package rebuilt gdb with -Os debug some program

2011-09-29 Thread xunxun 

Hi, all

I found a weird problem when I rebuilt gdb using Ruben's gcc4.6 
stdthread package.


Reproduce process:

1. Download Ruben's gcc4.6 stdthread 32bit package.

2. Configure gdb --with-python --with-expat

3. make script :

make -j2 BOOT_CFLAGS=-pipe -g3 -Os\
CFLAGS=-pipe -g3 -Os\
CXXFLAGS=-pipe -g3 -Os   -mthreads   \
CFLAGS_FOR_TARGET=-pipe -g3 -Os\
CXXFLAGS_FOR_TARGET=-pipe -g3 -Os   -mthreads   \
BOOT_CXXFLAGS=-pipe -g3 -Os   -mthreads   \
  CFLAGS_FOR_BUILD=-pipe -g3 -Os\
  CXXFLAGS_FOR_BUILD=-pipe -g3 -Os  -mthreads   \
LDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,--large-address-aware  \
LDFLAGS_FOR_BUILD=-Wl,-O1 -Wl,--as-needed 
-Wl,--large-address-aware  \

BOOT_LDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,--large-address-aware  \
LDFLAGS_FOR_TARGET=-Wl,-O1 -Wl,--as-needed 
-Wl,--large-address-aware  -static   


Then I use the new rebuilt gdb to debug other programs, and it can't 
list source code, and if you input list twice, gdb will crash.


The debug log:
--
GNU gdb (GDB) 7.3.1.20110921-cvs
Copyright (C) 2011 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 i686-w64-mingw32.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from E:\MyPack\MinGW\bin/gdb-1.exe...done.
(gdb) run
Starting program: E:\MyPack\MinGW\bin/gdb-1.exe
[New Thread 2212.0x1ba8]
GNU gdb (pcx32) 7.3.1
Copyright (C) 2011 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 i686-w64-mingw32.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
(gdb) file a.exe
Reading symbols from e:\t\temp\a.exe...done.
(gdb) l
(gdb) No source file named main.
l
[New Thread 2212.0xe34]
[New Thread 2212.0x654]

Program received signal SIGSEGV, Segmentation fault.
0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING) at 
exceptions.c:126

126  switch (current_catcher-state)
(gdb) warning: Could not load shared library symbols for 20 libraries, 
e.g. C:\Windows\system32\ntdll.dll.

Use the info sharedlibrary command to see the complete listing.
Do you need set solib-search-path or set sysroot?
warning: Could not load shared library symbols for 
C:\Windows\SysWOW64\imm32.dll.

Do you need set solib-search-path or set sysroot?
warning: Could not load shared library symbols for 
C:\Windows\syswow64\msctf.dll.

Do you need set solib-search-path or set sysroot?
warning: Could not load shared library symbols for 
C:\Windows\syswow64\psapi.dll.

Do you need set solib-search-path or set sysroot?
bt
#0  0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING)
at exceptions.c:126
#1  0x0041ad0d in throw_exception (exception=...) at exceptions.c:240
#2  0x0041ae68 in exceptions_state_mc (action=optimized out)
at exceptions.c:191
#3  0x0041b1d4 in catch_errors (func=0x40181e captured_main,
func_args=0x28fe90, errstring=0x614070 , mask=6) at exceptions.c:519
#4  0x0040262c in gdb_main (args=0x28fe90) at ./main.c:949
#5  0x00608ef0 in main (argc=1, argv=0x3f2fc0) at gdb.c:35
(gdb) bt 30
#0  0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING)
at exceptions.c:126
#1  0x0041ad0d in throw_exception (exception=...) at exceptions.c:240
#2  0x0041ae68 in exceptions_state_mc (action=optimized out)
at exceptions.c:191
#3  0x0041b1d4 in catch_errors (func=0x40181e captured_main,
func_args=0x28fe90, errstring=0x614070 , mask=6) at exceptions.c:519
#4  0x0040262c in gdb_main (args=0x28fe90) at ./main.c:949
#5  0x00608ef0 in main (argc=1, argv=0x3f2fc0) at gdb.c:35
(gdb) q
A debugging session is active.

Inferior 1 [process 2212] will be killed.

Quit anyway? (y or n)
 



And if I replace -Os with -O2 to rebuild again, gdb will work ok.

In the same, my built posix thread with stdthread gcc 4.6 static edition 
also has the issue, but my old built win32 thread gcc4.6 has not the 
problem.


I don't know why.

Any ideas?

Thanks.

--
Best Regards,
xunxun

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.