Menu
▾
▴
mingw-users
|
From: leledumbo <lel...@ya...> - 2009-07-21 03:50:31
|
What should I do to convert application that uses setjmp / longjmp so that it can use dwarf-2 exception? Using the old model still compiles, but it generates segmentation fault instead of recovering from the exception. -- View this message in context: http://www.nabble.com/Converting-app-that-uses-SJLJ-exception-to-Dwarf-2-tp24581262p24581262.html Sent from the MinGW - User mailing list archive at Nabble.com. |
|
From: JonY <10...@gm...> - 2009-07-21 10:27:05
|
On 7/21/2009 11:50, leledumbo wrote: > > What should I do to convert application that uses setjmp / longjmp so that it > can use dwarf-2 exception? Using the old model still compiles, but it > generates segmentation fault instead of recovering from the exception. Hi, have you tried recompiling both applications with the same version of GCC? |
|
From: leledumbo <lel...@ya...> - 2009-07-22 04:13:38
|
> Hi, > have you tried recompiling both applications with the same version of GCC? Both? There's only one application. It uses setjmp / longjmp to handle exceptions, but on every exception it crashes instead of get handled. -- View this message in context: http://www.nabble.com/Converting-app-that-uses-SJLJ-exception-to-Dwarf-2-tp24581262p24599806.html Sent from the MinGW - User mailing list archive at Nabble.com. |
|
From: JonY <10...@gm...> - 2009-07-22 11:26:58
|
On 7/22/2009 12:13, leledumbo wrote: > >> Hi, >> have you tried recompiling both applications with the same version of GCC? > > Both? There's only one application. It uses setjmp / longjmp to handle > exceptions, but on every exception it crashes instead of get handled. Hi, I meant recompile both throw and catch sides with the same compiler. I am under the impression you are having issues with C++ applications. Do you mean C setjmp() and longjmp() from setjmp.h? If the latter case, it has nothing to do with C++ exception handling. Can you provide a minimal test case to demonstrate this? |
|
From: leledumbo <lel...@ya...> - 2009-07-23 07:25:05
|
> I am under the impression you are having issues with C++ applications. Not really, but a "clean" ANSI C that also compiles fine as C++. OK, I'll say what it is. It's the official Lua language implementation. > Do you mean C setjmp() and longjmp() from setjmp.h? > If the latter case, it has nothing to do with C++ exception handling. It is. So, is it OK to use them with gcc 4.4.0? If yes, I wonder where that crashes come from... > Can you provide a minimal test case to demonstrate this? Since it happens inside Lua interpreter (which is just a wrapper over the big library), I'm not sure. Just build Lua with gcc 4.4.0 and try some runtime problematic program. -- View this message in context: http://www.nabble.com/Converting-app-that-uses-SJLJ-exception-to-Dwarf-2-tp24581262p24620662.html Sent from the MinGW - User mailing list archive at Nabble.com. |
|
From: JonY <10...@gm...> - 2009-07-23 11:26:49
|
On 7/23/2009 15:24, leledumbo wrote: > >> I am under the impression you are having issues with C++ applications. > > Not really, but a "clean" ANSI C that also compiles fine as C++. OK, I'll > say what it is. It's the official Lua language implementation. > Hi, Well, clean ANSI C don't exactly throw exceptions. >> Do you mean C setjmp() and longjmp() from setjmp.h? >> If the latter case, it has nothing to do with C++ exception handling. > > It is. So, is it OK to use them with gcc 4.4.0? If yes, I wonder where that > crashes come from... > Have you tried GDB or WinDbg? >> Can you provide a minimal test case to demonstrate this? > > Since it happens inside Lua interpreter (which is just a wrapper over the > big library), I'm not sure. Just build Lua with gcc 4.4.0 and try some > runtime problematic program. I am unfamiliar with Lua, maybe you can CC the Lua devs for help. |
|
From: leledumbo <lel...@ya...> - 2009-07-24 03:55:04
|
> Well, clean ANSI C don't exactly throw exceptions. Even via setjmp and longjmp? > Have you tried GDB or WinDbg? Yes, GDB only tells segmentation fault without a proper backtrace (perhaps I didn't include the debug info correctly, I'll rebuild and check) > I am unfamiliar with Lua, maybe you can CC the Lua devs for help. Hmm... good idea, I hope they don't give "use Visual C++" as a solution. -- View this message in context: http://www.nabble.com/Converting-app-that-uses-SJLJ-exception-to-Dwarf-2-tp24581262p24638257.html Sent from the MinGW - User mailing list archive at Nabble.com. |
|
From: Keith M. <kei...@us...> - 2009-07-24 17:03:56
|
On Friday 24 July 2009 04:54:58 leledumbo wrote: > > Well, clean ANSI C don't exactly throw exceptions. > > Even via setjmp and longjmp? No. ANSI-C doesn't formalise *any* exception handling model. (The only references to exceptions, in the sense of abnormal condition traps, in the ANSI-C standard is to floating-point exceptions, but these aren't related to the C++ exception handling model). That GCC-C++ formerly offered a setjmp/longjmp exception model does not, in any way, imply that setjmp/longjmp relate exclusively to exception handling. Your fixation with exceptions is likely to be distracting you from the true cause of your problem. > > Have you tried GDB or WinDbg? > > Yes, GDB only tells segmentation fault ... So, your application is attempting to access memory outside of its allowed addressing range, or it is trying to write data into a read only data section. The single most common cause of the former segfault condition is any dereference of a NULL (likely uninitialised) pointer. Causes of the latter condition may be less obvious; here's an example of incorrect code, which will segfault when compiled with GCC, but may *appear* to work, if compiled with MSVC: . char *text = "some random text"; . strcpy( text, "new text" ); . > without a proper backtrace > (perhaps I didn't include the debug info correctly, I'll rebuild > and check) Have you tried *stepping* through your code, to locate the problem context? It is most likely that there is an invalid memory access bug in your code; newer versions of GCC are becoming more stringent in their rejection of invalid code, such as shown in the example above, (which would already fail with GCC-3.4). This increased intolerance of invalid code is a more likely explanation for the fault appearing with the newer GCC version, than the change in the C++ exception handling model, (*especially* when you aren't using C++ anyway). -- Regards, Keith. |
|
From: JonY <10...@gm...> - 2009-07-24 14:34:19
|
On 7/24/2009 11:54, leledumbo wrote: > >> Well, clean ANSI C don't exactly throw exceptions. > > Even via setjmp and longjmp? > Hi, You seem to be confusing what GCC uses for C++ exception mechanism and C setjmp and longjmp. Whichever exception model is used for C++, it does not affect C. |
|
From: leledumbo <lel...@ya...> - 2009-07-27 04:35:59
|
> You seem to be confusing what GCC uses for C++ exception mechanism and C > setjmp and longjmp. > > Whichever exception model is used for C++, it does not affect C. I guess I am. Still need to know why MSVC generated binaries run well... -- View this message in context: http://www.nabble.com/Converting-app-that-uses-SJLJ-exception-to-Dwarf-2-tp24581262p24673472.html Sent from the MinGW - User mailing list archive at Nabble.com. |
|
From: Keith M. <kei...@us...> - 2009-07-27 07:15:51
|
On Monday 27 July 2009 05:35:46 leledumbo wrote: > Still need to know why MSVC generated binaries run well... I've already given you one example of why that might be. Did you read it? -- Regards, Keith. |
|
From: leledumbo <lel...@ya...> - 2009-07-27 08:15:03
|
> I've already given you one example of why that might be. Did you > read it? Uh-huh, though I believe that's not the cause. I'm asking the Lua devs. -- View this message in context: http://www.nabble.com/Converting-app-that-uses-SJLJ-exception-to-Dwarf-2-tp24581262p24675541.html Sent from the MinGW - User mailing list archive at Nabble.com. |
|
From: Keith M. <kei...@us...> - 2009-07-27 17:11:36
|
On Monday 27 July 2009 09:14:53 leledumbo wrote: > > I've already given you one example of why that might be. Did > > you read it? > > Uh-huh, though I believe that's not the cause. Maybe not that, exactly, but likely something similar -- invalid source code, which results in different undefined behaviour with different compilers. -- Regards, Keith. |
|
From: Mark <mar...@gm...> - 2009-07-27 17:27:27
|
Keith Marshall wrote: > On Monday 27 July 2009 09:14:53 leledumbo wrote: > >>> I've already given you one example of why that might be. Did >>> you read it? >>> >> Uh-huh, though I believe that's not the cause. >> > > Maybe not that, exactly, but likely something similar -- invalid > source code, which results in different undefined behaviour with > different compilers. > One particular gotcha in setjmp is when the stack is too modified at resume; for instance when resuming after a function is already complete; without seeing the actual code that is upsetting you, I'd say it would be possible that compiler optimization makes the difference between the cases Best regards Mark http://www.halloit.com Key ID 046B65CF |
|
From: Keith M. <kei...@us...> - 2009-07-27 21:09:46
|
On Monday 27 July 2009 18:27:17 Mark wrote: > One particular gotcha in setjmp is when the stack is too modified > at resume; for instance when resuming after a function is already > complete; without seeing the actual code that is upsetting you, > I'd say it would be possible that compiler optimization makes the > difference between the cases It isn't even certain that setjmp is involved at all. The OP seems to have jumped to a conclusion that the switch from SJLJ exception handling to the Dwarf-2 model is somehow responsible, but that clearly isn't the case, because there is no exception handler in play; (the code is C, and the EH model is exclusive to C++). Since we haven't been shown any code, or even any diagnostics, we really can't offer anything but sheer speculation anyway. -- Regards, Keith. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X