From: Hans-Jochen T. <hj...@tx...> - 2010-03-09 18:15:31
|
> If you can supply a minimal test case to reproduce this problem, I'd > like to test for you. It seems like the size of the executable and the operation from inside Eclipse Galileo are essential to the problem. Starting from the command line in a console window gets the program off the ground just fine, and the program dies only where I know it should as I have meanwhile pretty much understood what the specific problem there is. Eclipse takes a long time (10+ seconds) to load the executable, and one of the two error messages say that "Target request failed. Target is not responding (timed out)." The other is the one on the internal error. I have a .gdbinit file now with a line "set remotetimeout 20" but that does not make any difference. I suspect that this particular timeout setting has nothing to do with the one referred to by the error message. I have a total of 5 applications (plus a dynamic library) in my Eclipse/MinGW environment. Two are small console applications, pure C++, and run fine under the debugger. One is a wxWidgets sample with a single (.cpp) source file and runs fine. The next is a wxWidgets app I wrote recently using DialogBlocks for the UI design, has 10 source files of 256 kB total and runs fine. The last is my offender with 62 source files of 2 MB total. That's what enforces my thinking that the large size of the app, and its related slow loading of the executable for debugging in Eclipse, are essential to the issue. At this time, I cannot afford to do a tedious cut-down of the app to see when/how the error might be made to go away or what the minimum needed is to have the error survive. I'll look into manually updating gcc to 4.4.x; 3.4.5 is what comes with MinGW 5.1.6. In any case, I appreciate your offer to help. Cheers, Jochen |
From: Hans-Jochen T. <hj...@tx...> - 2010-03-13 06:56:47
|
I have been digging some more and found the following: - The error I have originally reported for using gdb 6.8 is a user error. Once that is fixed, the result is the same as for 7.0.50, except for the line number in breakpoint.c referred to. - gdb 6.8, 7.0.1 and 7.0.50.20100202 all give essentially the same results. - With gcc 3.4.5, only my big app fails, 4 others (two wxWidgets, 2 plain C++) work. - With gcc 4.4.0 (via MinGW's download page at SourceForge), all 5 apps fail with an error code 0xc0000135. - All combinations of gdb and gcc run fine for all 5 programs from the command line, even taking into account the sequence of gdb commands that Eclipse CDT issues before actually calling to run the object program. - Eclipse Ganymede and Eclipse CDT give essentially the same results. Has anybody seen anything like this before? By the way, I have begun to ask at Eclipse.org also, thinking that the pattern of failures makes it a likely candidate for causing the problems. Cheers, Jochen |
From: Earnie <ea...@us...> - 2010-03-13 12:52:18
|
Hans-Jochen Trost wrote: > - With gcc 4.4.0 (via MinGW's download page at SourceForge), all 5 > apps fail with an error code 0xc0000135. > Are you sure this is an error code? Seems more like a memory address. Earnie |
From: Jochen T. <hj...@tx...> - 2010-03-13 17:16:32
|
Earnie, the exact message in the console log of Eclipse (stderr, I suppose) is Unknown target exception 0xc0000135 at 0x7c9666c6 During startup program exited with code 0xc0000135. That feels like a code 0xc0000005, which is in Windows an access violation. I'm not at work and can't review the full logs, but the quoted address 0x7c9666c6 is not too far from a reasonable one that correlates with the actual object program (I remember something beginning 0x7c90....). Cheers, Jochen -----Original Message----- Message: 6 Date: Sat, 13 Mar 2010 07:52:05 -0500 From: Earnie <ea...@us...> Subject: Re: [Mingw-users] "Internal error" in gdb 7.0.50.20100202 [snip] Hans-Jochen Trost wrote: > - With gcc 4.4.0 (via MinGW's download page at SourceForge), all 5 > apps fail with an error code 0xc0000135. > Are you sure this is an error code? Seems more like a memory address. |
From: Hans-Jochen T. <hj...@tx...> - 2010-03-23 19:53:24
|
A tip I received in the Eclipse CDT forum got me digging in the right direction. The 0xC0000135 error means "missing component", which may be a driver or DLL. The basic problem was that, at least with gcc 4.4.0 in place, gdb needs the system-wide PATH setting (Control Panel -> System -> Advanced -> Environment Variables) to include at least MinGWin if not even MSYSin (or MSYS.0in). That fixed it and the debugging run proceeds as expected to the point where I am responsible for a crash in my own program, and gdb's diagnosis at that point is the correct one. I am using a DLL loaded at start time that is independent of the Windows system DLL, and if that one cannot be found, the same 0xc0000135 occurs. Despite the path fix, the original failure symptoms that I reported using gcc 3.4.5 remain unchanged, i.e., my smaller programs went through fine but my large program exposes an "internal error" in breakpoint.c. What is curious in this regard is that with 3.4.5, gdb did not require the Windows path modification. I'm happy to stick with gcc 4.4.0 and will not pursue the 3.4.5 issue further. Thus, I consider this topic closed. -- Hans-Jochen Trost 1629 University Drive Richardson, TX 75081 USA Phone: +1 (972) 889-0328 E-mail: hj...@ma... |
From: Hans-Jochen T. <hj...@tx...> - 2010-03-24 04:49:40
|
I apologize for the distorted text. I don't quite understand what happened in the webmail client I have used. Here is the first paragraph again: A tip I received in the Eclipse CDT forum got me digging in the right direction. The 0xC0000135 error means "missing component", which may be a driver or DLL. The basic problem was that, at least with gcc 4.4.0 in place, gdb needs the system-wide PATH setting (Control Panel -> System -> Advanced -> Environment Variables) to include at least MinGW\bin if not even MSYS\bin (or MSYS\1.0\bin). That fixed it and the debugging run proceeds as expected to the point where I am responsible for a crash in my own program, and gdb's diagnosis at that point is the correct one. I am using a DLL loaded at start time that is independent of the Windows system DLL, and if that one cannot be found, the same 0xc0000135 occurs. Cheers, Jochen |