Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 03, 2007 hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
I've been running into problems with gdc for a while now (.21-.23, mingw32, 3.4.5 and 4.1.2), specifically crashes in odd places (language constructs). It only seems to happen when I run many threads in parallel; are there any known issues with that? Here's a log of a debugging session I made recently, after rebuilding Phobos without -O2 (Line space added): D:\code\d\yawr>gdb bin\dbg\yawr.exe GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"... (gdb) r Starting program: D:\code\d\yawr/bin\dbg\yawr.exe Program received signal SIGSEGV, Segmentation fault. [Switching to thread 2448.0xb18] 0x022cfea9 in ?? () (gdb) bt #0 0x022cfea9 in ?? () #1 0x00421525 in _d_throw (obj=@0x1e17770) at ../../../gcc-4.1.2/libphobos/gcc/deh.d:99 #2 0x0042df41 in _D3std6socket15InternetAddress5_ctorMFAatZC3std6socket15Intern etAddress (this=@0x1ea51a0, addr= {length = 18, ptr = 0x1bf4a67 "talismenseries.com/"}, port=80) at ../../../gcc-4.1.2/libphobos/std/socket.d:676 #3 0x0040337b in _D4main11do_DownloadFAaZAa (param= {length = 26, ptr = 0x1bf4a60 "http://talismenseries.com/"}) at main.d:67 #4 0x0040aed7 in _D4main8downloadFAaDFfZvZAa13__dgliteral26MFAaZAa (c= {length = 26, ptr = 0x1bf4a60 "http://talismenseries.com/"}) at main.d:830 #5 0x00410692 in _D5tools6buffer17__T6bufferTAaTAaZ6buffer3getMFAaZAa13__dglite ral73MFZb () at tools/buffer.d:37 #6 0x00547cc2 in _D5tools6buffer17__T6bufferTAaTAaZ6buffer3getMFAaZAa ( this=@0x1e73c80, idx= {length = 26, ptr = 0x1bf4a60 "http://talismenseries.com/"}) at tools/buffer.d:28 #7 0x0040ae84 in _D4main8downloadFAaDFfZvZAa (url= {length = 26, ptr = 0x1bf4a60 "http://talismenseries.com/"}, progress= {object = 0x52cfe8c, func = 0x411387 <_D4main17__T6fhtagnVb0Vb0Z6fhtagn6up dateMFDFZvZv13__dgliteral87MFfZv>}) at main.d:834 #8 0x0053dec1 in _D4main17__T6fhtagnVb0Vb0Z6fhtagn6updateMFDFZvZv ( ---Type <return> to continue, or q <return> to quit--- this=@0x1da1880, redraw= {object = 0x1df2a80, func = 0x40b912 <_D4main14user_interface7refreshMFZv> }) at main.d:535 #9 0x00538579 in _D3std4bind101__T9BoundFuncTDFDFZvZvS41_D3std4bind9NullAliasS3 std4bind9EmptySlotTS3std4bind15__T5TupleTDFZvZ5TupleZ9BoundFunc16__T10MBoundFunc Z4funcMFZv (this=@0x1c48d00) at c:/mingw/bin/../lib/gcc/mingw32/4.1.2/../../../../include/d/4.1.2/std/bin d.d:527 #10 0x0041001d in _D4main10poolthread3runMFZi (this=@0x1de7080) at main.d:1256 #11 0x0043a75f in _D3std6thread6Thread11threadstartWPvZk@4 (p=0x1de7080) at ../../../gcc-4.1.2/libphobos/std/thread.d:412 #12 0x77c3a3b0 in _libws2_32_a_iname () #13 0x7c80b683 in _libws2_32_a_iname () (gdb) f 1 #1 0x00421525 in _d_throw (obj=@0x1e17770) at ../../../gcc-4.1.2/libphobos/gcc/deh.d:99 99 _Unwind_SjLj_RaiseException (&exc.unwindHeader); (gdb) i loc exc = (OurUnwindException *) 0x1e16800 (gdb) p *exc $1 = {handlerSwitchValue = 0, actionRecord = 0x0, languageSpecificData = 0x0, catchTemp = 0, landingPad = 0, obj = @0x1e17770, unwindHeader = { exception_class = 26844869579591239, exception_cleanup = 0x421495 <_gdc_cleanupException>, private_1 = 0, private_2 = 0}} (gdb) Any idea how to proceed from here? This error has me totally stumped. (if anybody wants to read the source, it's in yawr.svn.sourceforge.net/viewvc/yawr/ ) Could this be related to stack corruption/buffer overflows? The backtrace looks intact but I used to have issues with stack corruption in connection with SDL .. I believed I had fixed these, but it is possible that errors remain. Ideas? -- slightly despairing, downs |
April 04, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Downs Attachments: | Downs schrieb am 2007-04-03: > I've been running into problems with gdc for a while now (.21-.23, mingw32, 3.4.5 and 4.1.2), specifically crashes in odd places (language constructs). > It only seems to happen when I run many threads in parallel; are there any known issues with that? > (gdb) bt > #0 0x022cfea9 in ?? () > #1 0x00421525 in _d_throw (obj=@0x1e17770) > at ../../../gcc-4.1.2/libphobos/gcc/deh.d:99 > #2 0x0042df41 in _D3std6socket15InternetAddress5_ctorMFAatZC3std6socket15Intern > etAddress (this=@0x1ea51a0, addr= > {length = 18, ptr = 0x1bf4a67 "talismenseries.com/"}, port=80) > at ../../../gcc-4.1.2/libphobos/std/socket.d:676 [...] Phobos' socket implementation isn't re-entrant save (e.g. gethostbyname instead of gethostbyname_r). This might cause exceptions even if the host actually exists. Regardless, #2 looks sane. Judging form the other data #1's obj seems to be a valid address. #0 should be somewhere inside _Unwind_SjLj_RaiseException. GCC-4.1.2's doesn't document _Unwind_SjLj_RaiseException apart from "document me!". Thus one question would be: what happens if more than one thread tries to unwind at the same time? Thomas |
April 05, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Kuehne | Thomas Kuehne wrote: > > Phobos' socket implementation isn't re-entrant save (e.g. gethostbyname > instead of gethostbyname_r). Yup, I noticed. Thus, the entire section is synchronized. (Win32 has no gethostbyname_r, sadly) > This might cause exceptions even if the > host actually exists. Regardless, #2 looks sane. Judging form the other > data #1's obj seems to be a valid address. #0 should be somewhere inside > _Unwind_SjLj_RaiseException. > > GCC-4.1.2's doesn't document _Unwind_SjLj_RaiseException apart from > "document me!". Thus one question would be: what happens if more than one > thread tries to unwind at the same time? > Well that _might_ be it, but that error always happens in the same spot, so a threading issue seems slightly unlikely, especially since the area is, as aforementioned, synched. ... It _might_ be that the error just went away, though. The problem with errors in network code is always that error conditions (that rely on external sites) might be hard to reproduce. Well, if it did go away, then all for the better. ^^ Too bad you can't prove absence :/ > Thomas > > > -----BEGIN PGP SIGNATURE----- > > iD8DBQFGFDwnLK5blCcjpWoRAo7DAJ98Mu4lnWm38ySHAJ0+Zl7gQ3ElTwCghbVR > WWeq56yF71r41YZaaDfG5IU= > =DJBz > -----END PGP SIGNATURE----- -- downs |
April 11, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Downs | Update! It might be related to something that I think is a GC bug. Consider, please, the following GDB session. To sum it up, I have a character array in a struct in a dynamic array in another struct in a class instance, pointed to by the main program. And apparently the char array gets collected, since the hardware watchpoints show how the memory area it points to is being overwritten by a new object. When I std.gc.disable, the problem goes away. D:\code\d\yawr>gdb bin\dbg\yawr.exe GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"... (gdb) b main.d:353 Breakpoint 1 at 0x406dca: file main.d, line 353. (gdb) r Starting program: D:\code\d\yawr/bin\dbg\yawr.exe [Switching to thread 3708.0x16a0] Breakpoint 1, _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 353 sgms[part]++; flush; got(); redraw(); (gdb) c Continuing. Breakpoint 1, _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 353 sgms[part]++; flush; got(); redraw(); (gdb) p this.data.pages $1 = {length = 2, ptr = 0x2fbb200} (gdb) p *(this.data.pages.ptr) $2 = {url = {length = 45, ptr = 0x2d38140 "www.earthsongsaga.com/images/Redux/cover1.jpg"}, title = { length = 16, ptr = 0x2d6eb31 "December 1, 2005 </strong></p>\r\n <p>I'd like to th ank all of you who took the time to write me emails of congratulations re: my en gagement - it was very touching *has much love for all her read"...}, chapter = {length = 0, ptr = 0x0}, read = false, reserve = {length = 0, ptr = 0x0}} (gdb) i thr 5 thread 3708.0x15bc 0x7c90eb94 in _libws2_32_a_iname () 4 thread 3708.0xcf0 0x7c90eb94 in _libws2_32_a_iname () 3 thread 3708.0x148c 0x7c90eb94 in _libws2_32_a_iname () * 2 thread 3708.0x16a0 _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 1 thread 3708.0x318 0x7c90eb94 in _libws2_32_a_iname () (gdb) watch *(int*)0x2d38140 Hardware watchpoint 2: *(int *) 47415616 (gdb) thr 3 [Switching to thread 3 (thread 3708.0x148c)]#0 0x7c90eb94 in _libws2_32_a_iname () (gdb) watch *(int*)0x2d38140 Hardware watchpoint 3: *(int *) 47415616 (gdb) thr 4 [Switching to thread 4 (thread 3708.0xcf0)]#0 0x7c90eb94 in _libws2_32_a_iname () (gdb) watch *(int*)0x2d38140 Hardware watchpoint 4: *(int *) 47415616 (gdb) thr 5 [Switching to thread 5 (thread 3708.0x15bc)]#0 0x7c90eb94 in _libws2_32_a_iname () (gdb) watch *(int*)0x2d38140 Hardware watchpoint 5: *(int *) 47415616 (gdb) c Continuing. [Switching to thread 3708.0x16a0] Breakpoint 1, _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 353 sgms[part]++; flush; got(); redraw(); (gdb) p *(this.data.pages) Structure has no component named operator*. (gdb) p *(this.data.pages.ptr) $3 = {url = {length = 45, ptr = 0x2d38140 "www.earthsongsaga.com/images/Redux/cover1.jpg"}, title = { length = 16, ptr = 0x2d6eb31 "December 1, 2005 </strong></p>\r\n <p>I'd like to th ank all of you who took the time to write me emails of congratulations re: my en gagement - it was very touching *has much love for all her read"...}, chapter = {length = 0, ptr = 0x0}, read = false, reserve = {length = 0, ptr = 0x0}} (gdb) c Continuing. Breakpoint 1, _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 353 sgms[part]++; flush; got(); redraw(); (gdb) p *(this.data.pages.ptr) $4 = {url = {length = 45, ptr = 0x2d38140 "www.earthsongsaga.com/images/Redux/cover1.jpg"}, title = { length = 16, ptr = 0x2d6eb31 "December 1, 2005 </strong></p>\r\n <p>I'd like to th ank all of you who took the time to write me emails of congratulations re: my en gagement - it was very touching *has much love for all her read"...}, chapter = {length = 0, ptr = 0x0}, read = false, reserve = {length = 0, ptr = 0x0}} (gdb) c Continuing. Breakpoint 1, _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 353 sgms[part]++; flush; got(); redraw(); (gdb) p *(this.data.pages.ptr) $5 = {url = {length = 45, ptr = 0x2d38140 "www.earthsongsaga.com/images/Redux/cover1.jpg"}, title = { length = 16, ptr = 0x2d6eb31 "December 1, 2005 </strong></p>\r\n <p>I'd like to th ank all of you who took the time to write me emails of congratulations re: my en gagement - it was very touching *has much love for all her read"...}, chapter = {length = 0, ptr = 0x0}, read = false, reserve = {length = 0, ptr = 0x0}} (gdb) c Continuing. Breakpoint 1, _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 353 sgms[part]++; flush; got(); redraw(); (gdb) c Continuing. Breakpoint 1, _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 353 sgms[part]++; flush; got(); redraw(); (gdb) c Continuing. Breakpoint 1, _D4main9earthsong6updateMFDFZvDFZvZv (this=@0x1304780, redraw= {object = 0x1df6380, func = 0x40c712 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1ebcdc0, func = 0x53a570 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:353 353 sgms[part]++; flush; got(); redraw(); (gdb) p *(this.data.pages.ptr) $6 = {url = {length = 45, ptr = 0x2d38140 "www.earthsongsaga.com/images/Redux/cover1.jpg"}, title = { length = 16, ptr = 0x2d6eb31 "December 1, 2005 </strong></p>\r\n <p>I'd like to th ank all of you who took the time to write me emails of congratulations re: my en gagement - it was very touching *has much love for all her read"...}, chapter = {length = 0, ptr = 0x0}, read = false, reserve = {length = 0, ptr = 0x0}} (gdb) d 1 (gdb) c Continuing. [Switching to thread 3708.0x318] Hardware watchpoint 2: *(int *) 47415616 Old value = 779581303 New value = 0 Hardware watchpoint 3: *(int *) 47415616 Old value = 779581303 New value = 0 Hardware watchpoint 4: *(int *) 47415616 Old value = 779581303 New value = 0 Hardware watchpoint 5: *(int *) 47415616 Old value = 779581303 New value = 0 0x0042acb0 in _d_newclass (ci=@0x54e530) at ../../../gcc-4.1.2/libphobos/internal/gc/gc.d:170 170 (cast(byte*)p)[0 .. ci.init.length] = ci.init[]; (gdb) bt #0 0x0042acb0 in _d_newclass (ci=@0x54e530) at ../../../gcc-4.1.2/libphobos/internal/gc/gc.d:170 #1 0x0040de1d in _D4main14user_interface13buildTreeviewMFkkZAC7widgets6widget (this=@0x1df6380, start=0, end=23) at main.d:1063 #2 0x0054bd84 in _D7widgets29__T7dgArrayTC7widgets6widgetZ7dgArray6opCallMFkkZA C7widgets6widget (this=0x1df61a8, start=0, end=23) at widgets.d:275 #3 0x0041fa49 in _D7widgets14fixedscrollbox4drawMFPS3SDL11SDL_SurfaceZv ( this=@0x1df6180, surf=0xf15c68) at widgets.d:796 #4 0x00419f19 in _D7widgets15compositeWidget4drawMFPS3SDL11SDL_SurfaceZv ( this=@0x1e1c800, surf=0xf15c68) at widgets.d:179 #5 0x00420747 in _D7widgets10fixedSplit4drawMFPS3SDL11SDL_SurfaceZv ( this=@0x1e1c800, surf=0xf15c68) at widgets.d:876 #6 0x00419f19 in _D7widgets15compositeWidget4drawMFPS3SDL11SDL_SurfaceZv ( this=@0x1e1ca80, surf=0xf15c68) at widgets.d:179 #7 0x0041e996 in _D7widgets11splitWidget4drawMFPS3SDL11SDL_SurfaceZv ( this=@0x1e1ca80, surf=0xf15c68) at widgets.d:700 #8 0x0041a314 in _D7widgets8callback4drawMFPS3SDL11SDL_SurfaceZv ( this=@0x1e1ccc0, surf=0xf15c68) at widgets.d:215 #9 0x0041513c in _D10sdl_bridge10sdl_bridge10mustRedrawMFZb (this=@0x1e1b620) at sdl_bridge.d:27 #10 0x004156a1 in _D10sdl_bridge10sdl_bridge4idleMFZv (this=@0x1e1b620) at sdl_bridge.d:81 #11 0x00419d01 in _D7widgets9ui_bridge4loopMFZv (this=@0x1e1b620) ---Type <return> to continue, or q <return> to quit--- at widgets.d:156 #12 0x00410200 in _D4main14user_interface3runMFZv (this=@0x1df6380) at main.d:1251 #13 0x004108f7 in _D4main4MainFAAaZi (args={length = 1, ptr = 0xd32720}) at main.d:1279 #14 0x0040563f in _Dmain (args={length = 2293416, ptr = 0x43f253}) at main.d:262 #15 0x0043f253 in _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi2goMFZv () at ../../../gcc-4.1.2/libphobos/internal/dgccmain2.d:83 #16 0x0043f0bf in _d_run_main (argc=1, argv=0xd33f88, main_func=0x40561c <_Dmain>) at ../../../gcc-4.1.2/libphobos/internal/dgccmain2.d:93 #17 0x00421018 in main (argc=2293680, argv=0x401237) at ../../../gcc-4.1.2/libphobos/internal/cmain.d:5 (gdb) f 13 #13 0x004108f7 in _D4main4MainFAAaZi (args={length = 1, ptr = 0xd32720}) at main.d:1279 1279 UserInterface.run; (gdb) p es $7 = (comic &) @0x1304780: {<> = {vptr = 0x55d3e0, monitor = 0x0}, data = { pages = {length = 10, ptr = 0x2d6ce00}, custom = {length = 16, ptr = 0x2d66890 "\003"}}, gotNew = true, updating = true, fs = @0xe10fc0} (gdb) p es.data.pages $8 = {length = 10, ptr = 0x2d6ce00} (gdb) p *(es.data.pages.ptr) $9 = {url = {length = 45, ptr = 0x2d38140 ""}, title = {length = 16, ptr = 0x2d6eb31 ""}, chapter = {length = 0, ptr = 0x0}, read = false, reserve = {length = 0, ptr = 0x0}} (gdb) q The program is running. Exit anyway? (y or n) y D:\code\d\yawr> |
April 11, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Downs | Downs wrote:
> Update!
Nevermind this please.
It turned out to be an unrelated bug in the GC.
|
April 11, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Downs | Downs wrote:
> Downs wrote:
>> Update!
>
> Nevermind this please.
> It turned out to be an unrelated bug in the GC.
Bug in the GC or bug in your app? If it's a bug in the GC, please narrow down the repro case as narrowly as possible and file it in bugzilla. If it's in your app, sharing the details of what was wrong and how you narrowed it down might help others avoid the problem or track down something similar in the future.
Later,
Brad
|
April 11, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | Brad Roberts wrote:
> Downs wrote:
>> Downs wrote:
>>> Update!
>>
>> Nevermind this please.
>> It turned out to be an unrelated bug in the GC.
>
> Bug in the GC or bug in your app? If it's a bug in the GC, please narrow down the repro case as narrowly as possible and file it in bugzilla. If it's in your app, sharing the details of what was wrong and how you narrowed it down might help others avoid the problem or track down something similar in the future.
>
> Later,
> Brad
Thanks for your answer.
I think it was a bug in the GC, but I'm not sure.
Reducing it to a testcase might be hard though, since it only happens sporadically in multithreaded mode, so the causes are hard to pin down.
Be that as it may, since setV1_0 made it go away, I'm labelling it "case closed".
Please understand that I'm simply unwilling to spend any more time (and nerves) on something which has ceased (finally) to be a problem for me.
greetings -- downs
|
April 11, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Downs | Downs wrote: > Thomas Kuehne wrote: >> >> This might cause exceptions even if the >> host actually exists. Regardless, #2 looks sane. Judging form the other >> data #1's obj seems to be a valid address. #0 should be somewhere inside >> _Unwind_SjLj_RaiseException. >> >> GCC-4.1.2's doesn't document _Unwind_SjLj_RaiseException apart from >> "document me!". Thus one question would be: what happens if more than one >> thread tries to unwind at the same time? >> > Here's another debugging session, obtained after rebuilding phobos, this time with more debugging info. It's another error, but they seem to be related. This one should be a little easier to understand (hopefully). Sadly, I have absolutely no idea what's going on here. Some kind of stack corruption? D:\code\d\yawr>gdb bin\dbg\yawr.exe GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"... (gdb) r Starting program: D:\code\d\yawr/bin\dbg\yawr.exe Program received signal SIGSEGV, Segmentation fault. [Switching to thread 5356.0xdb8] 0x0043f40b in read_uleb128 (p=0xa2f0000 <Address 0xa2f0000 out of bounds>, val=0xa2ef5f0) at ../../../gcc-4.1.2/libphobos/gcc/unwind.d:335 335 a_byte = *p++; (gdb) bt #0 0x0043f40b in read_uleb128 (p=0xa2f0000 <Address 0xa2f0000 out of bounds>, val=0xa2ef5f0) at ../../../gcc-4.1.2/libphobos/gcc/unwind.d:335 #1 0x004233f4 in _D3gcc3deh15personalityImplFiT3gcc6unwind14_Unwind_ActionmPS3g cc6unwind17_Unwind_ExceptionPS3gcc6unwind15_Unwind_ContextZk (iversion=1, actions=1, exception_class=26844869579591239, ue_header=0xef286d8, context=0xa2ef6b0) at ../../../gcc-4.1.2/libphobos/gcc/deh.d:202 #2 0x0042324a in __gdc_personality_sj0 (iversion=1, actions=1, exception_class=26844869579591239, ue_header=0xef286d8, context=0xa2ef6b0) at ../../../gcc-4.1.2/libphobos/gcc/deh.d:120 #3 0x00534092 in _Unwind_SjLj_RaiseException (exc=0xef286d8) at ../../gcc-4.1.2/gcc/unwind.inc:117 #4 0x00423205 in _d_throw (obj=@0xef37600) at ../../../gcc-4.1.2/libphobos/gcc/deh.d:99 #5 0x0042d773 in _d_array_bounds (filename= {length = 6, ptr = 0x55ce40 "main.d"}, line=113) at ../../../gcc-4.1.2/libphobos/std/array.d:38 #6 0x00403c02 in _D4main11do_DownloadFAaZAa (param= {length = 50, ptr = 0x1f28900 "http://www.shamusyoung.com/twentysidedtale/ ?p=1071"}) at main.d:113 #7 0x0040bb08 in _D4main8downloadFAaDFfZvZAa13__dgliteral27MFAaZAa (c= {length = 50, ptr = 0x1f28900 "http://www.shamusyoung.com/twentysidedtale/ ?p=1071"}) at main.d:879 #8 0x004118e2 in _D5tools6buffer17__T6bufferTAaTAaZ6buffer3getMFAaZAa13__dglite ---Type <return> to continue, or q <return> to quit--- ral77MFZb () at tools/buffer.d:37 #9 0x0054ada6 in _D5tools6buffer17__T6bufferTAaTAaZ6buffer3getMFAaZAa ( this=@0x1efb640, idx= {length = 50, ptr = 0x1f28900 "http://www.shamusyoung.com/twentysidedtale/ ?p=1071"}) at tools/buffer.d:28 #10 0x0040bab5 in _D4main8downloadFAaDFfZvZAa (url= {length = 50, ptr = 0x1f28900 "http://www.shamusyoung.com/twentysidedtale/ ?p=1071"}, progress= {object = 0xa2efe5c, func = 0x4129eb <_D4main17__T6fhtagnVb0Vb0Z6fhtagn6up dateMFDFZvDFZvZv13__dgliteral91MFfZv>}) at main.d:883 #11 0x005400ed in _D4main17__T6fhtagnVb0Vb0Z6fhtagn6updateMFDFZvDFZvZv ( this=@0x1cdd180, redraw= {object = 0x1e84600, func = 0x40c6f2 <_D4main14user_interface7refreshMFZv> }, got= {object = 0x1f24f80, func = 0x53a560 <_D3std4bind117__T9BoundFuncTDFC4main 5comicZvS41_D3std4bind9NullAliasS3std4bind9EmptySlotTS3std4bind23__T5TupleTC4mai n5comicZ5TupleZ9BoundFunc16__T10MBoundFuncZ4funcMFZv>}) at main.d:557 #12 0x0053a4cb in _D3std4bind110__T9BoundFuncTDFDFZvDFZvZvS41_D3std4bind9NullAli asS3std4bind9EmptySlotTS3std4bind20__T5TupleTDFZvTDFZvZ5TupleZ9BoundFunc16__T10M BoundFuncZ4funcMFZv (this=@0x1f24f60) at c:/mingw/bin/../lib/gcc/mingw32/4.1.2/../../../../include/d/4.1.2/std/bin d.d:527 #13 0x0041107f in _D4main10poolthread3runMFZi (this=@0x1e84e00) at main.d:1319 ---Type <return> to continue, or q <return> to quit--- #14 0x0043c70f in _D3std6thread6Thread11threadstartWPvZk@4 (p=0x1e84e00) at ../../../gcc-4.1.2/libphobos/std/thread.d:412 #15 0x77c3a3b0 in _libws2_32_a_iname () #16 0x7c80b683 in _libws2_32_a_iname () (gdb) |
April 11, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Downs | Downs escreveu: > Brad Roberts wrote: >> Downs wrote: >>> Downs wrote: >>>> Update! >>> >>> Nevermind this please. >>> It turned out to be an unrelated bug in the GC. >> >> Bug in the GC or bug in your app? If it's a bug in the GC, please narrow down the repro case as narrowly as possible and file it in bugzilla. If it's in your app, sharing the details of what was wrong and how you narrowed it down might help others avoid the problem or track down something similar in the future. >> [snipped] Downs, > I think it was a bug in the GC, but I'm not sure. Since you're sure, it may be it still there, and being a bug, it will appear sooner or later... > Reducing it to a testcase might be hard though, since it only happens sporadically in multithreaded mode, so the causes are hard to pin down. Try to put as much as you can in your app to pinpoint the problem once it appears in the future, it may be there dormant, but nevertheless capable of playing havoc when you less need it! > Be that as it may, since setV1_0 made it go away, I'm labelling it "case closed". > Please understand that I'm simply unwilling to spend any more time (and nerves) on something which has ceased (finally) to be a problem for me. I think all of us can understand your mood and your priorities, but forgetting about the bug doesn't fix it... |
April 11, 2007 Re: hardcore gdc problems | ||||
---|---|---|---|---|
| ||||
Posted in reply to Downs | Downs wrote:
> Brad Roberts wrote:
>> Downs wrote:
>>> Downs wrote:
>>>> Update!
>>>
>>> Nevermind this please.
>>> It turned out to be an unrelated bug in the GC.
>>
>> Bug in the GC or bug in your app? If it's a bug in the GC, please narrow down the repro case as narrowly as possible and file it in bugzilla. If it's in your app, sharing the details of what was wrong and how you narrowed it down might help others avoid the problem or track down something similar in the future.
>>
>> Later,
>> Brad
> Thanks for your answer.
> I think it was a bug in the GC, but I'm not sure.
> Reducing it to a testcase might be hard though, since it only happens sporadically in multithreaded mode, so the causes are hard to pin down.
> Be that as it may, since setV1_0 made it go away, I'm labelling it "case closed".
> Please understand that I'm simply unwilling to spend any more time (and nerves) on something which has ceased (finally) to be a problem for me.
If setV1_0 fixed this then the problem is most likely with an object containing pointers being marked as not containing pointers by the runtime. Post 1.0, the GC won't scan through these blocks and referenced data may be prematurely cleaned up. There were a bunch of bugs related to this after 1.0 and I think one or two corner cases may still exist. I would encourage anyone who finds data disappearing on them to please report it once they find the time :-)
Sean
|
Copyright © 1999-2021 by the D Language Foundation