Trouble is that this a few thousand line codebase. I'll see what I can do about getting a reduced sample. I was mostly wondering whether you've seen anything like this before, but it sounds like you haven't.
I initially thought it might be related to my use of Fibers, but removing them seems to have had no effect (although my program is faster now, so I suppose that's an effect). On Wed, Feb 15, 2012 at 2:28 PM, Daniel Green <[email protected]> wrote: > If you could post the source and a link to it I'd be happy to take a look. > Also bug reports are always welcomed especially when accompanied by reduced > testcases ;) > > > > On 2/9/2012 11:34 AM, Andrew Wiley wrote: >> >> On Thu, Feb 9, 2012 at 10:25 AM, Andrew Wiley<[email protected]> >> wrote: >>> >>> On Sat, Jan 28, 2012 at 8:46 AM, Daniel Green<[email protected]> wrote: >>> >>>> Please post all issues in D.gnu or on GDC's site >>>> https://bitbucket.org/goshawk/gdc >>>> >>>> Due to the use of a newer runtime than TDM64-GCC it is **recommended** >>>> to >>>> install a copy specifically for GDC. >>>> >>>> Features >>>> * binutils with TLS patches >>>> * mingw-w64-runtime with TLS and stdio fixes. >>>> * GCC 4.6.1 with TLS patches >>>> * Both D1 and D2 compilers. D2 invoked by default. >>>> * -v1 Compiles with D1. Must be used in linking stage as well. >>>> * -v2 Compiles with D2. Must be used in linking stage as well. >>>> >>>> MinGW64 installer >>>> http://tdm-gcc.tdragon.net/ >>>> >>>> GDC binary >>>> >>>> https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-232cd89d90b4-20120128.7z >>>> >>>> Known issues: >>>> * May break TDM64 C++. >>>> * Field-less structs will throw a null this exception. When formatted >>>> by >>>> std.format. runnable/test23.d >>>> >>>> --- >>>> >>>> For the time, MinGW32 binaries will not be provided. MinGW64 is built >>>> as a >>>> 32-bit binary that allows use on 32-bit Windows. GDC requires patches >>>> to >>>> binutils and the MinGW runtime to function properly. Until those >>>> patches >>>> make it into their official repositories only MinGW64 will be released. >>> >>> >>> I'm seeing a consistent hang on a multithreaded application that runs >>> under GDC on Linux. It seems to be hanging on startup shortly after it >>> starts a thread (which is odd because this is the second thread it >>> starts, not the first). >>> GDB shows that the original thread and the first thread started are in >>> ntdll!ZwWriteVirtualMemory and the new thread is in >>> KERNEL32!CtrlRoutine, but it doesn't show any functions from my >>> program in the backtrace, which makes me suspicious. >>> (the main thread shows unidentifiable functions in the backtrace and >>> causes GDB to emit internal error warnings when trying to print said >>> backtrace) >>> I initially thought it might be GC related, but runniing GC.disable() >>> on startup doesn't seem to have any effect. >>> >>> Is this known, or should I copy/paste a bunch of GDB output and file a >>> bug? >> >> >> Probably more interestingly, I don't know where that third thread is >> coming from. I only ever start two in my program at the moment. >> I can also just stuff the program source onto Github. It's not closed >> source. > >
