search for: _cxxthrowexception

...tart testing with the Win32 port. I tested Signals.cpp and verified that the CTRL/C handler works, as does the stack trace. In fact, here's a sample: 77E73887 (0xE06D7363 0x00000001 0x00000003 0x0012FF28), RaiseException()+0080 bytes(s) 10226DB9 (0x0012FF44 0x0040DEFC 0x00020024 0x00647373), _CxxThrowException()+0057 bytes(s) 00401822 (0x0012FFC0 0x00409A2C 0x00000001 0x003250D0), XYZ::func()+0034 bytes(s), c:\projects\llvm\test.cpp, line 12 004017ED (0x00000001 0x003250D0 0x00322C68 0x00020024), main()+0013 bytes(s), c:\projects\llvm\test.cpp, line 19 00409A2C (0x00020024 0x7FFDF000 0x7FFDF000 0xF3893CF...

...rt. > > I tested Signals.cpp and verified that the CTRL/C handler works, as does > the stack trace. In fact, here's a sample: > > 77E73887 (0xE06D7363 0x00000001 0x00000003 0x0012FF28), RaiseException()+0080 bytes(s) > 10226DB9 (0x0012FF44 0x0040DEFC 0x00020024 0x00647373), _CxxThrowException()+0057 bytes(s) > 00401822 (0x0012FFC0 0x00409A2C 0x00000001 0x003250D0), XYZ::func()+0034 bytes(s), c:\projects\llvm\test.cpp, line 12 > 004017ED (0x00000001 0x003250D0 0x00322C68 0x00020024), main()+0013 bytes(s), c:\projects\llvm\test.cpp, line 19 > 00409A2C (0x00020024 0x7FFDF000 0x7FF...

...43ddaba3bcff6 More details about the crash: I was able to repro the issue simply by modifying the Fibonacci example to call an external C++ function which throws an exception, much like in ExceptionsDemo.cpp: works on 32 bits but not on 64 bits Visual Studio. The crash happens within Windows' _cxxThrowException routine. I read that the 64 bits exception handling in Windows is doing some unwinding in a different fashion than on 32 bits (as explained here: http://lackingrhoticity.blogspot.ca/2011/11/stack-unwinding-risks-on-64-bit-windows.html). In particular, this blog seems to state that exceptions won...

...ted Signals.cpp and verified that the CTRL/C handler works, as does > > the stack trace. In fact, here's a sample: > > > > 77E73887 (0xE06D7363 0x00000001 0x00000003 0x0012FF28), RaiseException()+0080 bytes(s) > > 10226DB9 (0x0012FF44 0x0040DEFC 0x00020024 0x00647373), _CxxThrowException()+0057 bytes(s) > > 00401822 (0x0012FFC0 0x00409A2C 0x00000001 0x003250D0), XYZ::func()+0034 bytes(s), c:\projects\llvm\test.cpp, line 12 > > 004017ED (0x00000001 0x003250D0 0x00322C68 0x00020024), main()+0013 bytes(s), c:\projects\llvm\test.cpp, line 19 > > 00409A2C (0x00020024 0...

...00000 7b835a72 00000003 0x0032fa34: 19930520 0032fab8 005659f0 7b97a9c0 0x0032fa44: 7b879258 7b8791bc 00001100 68a334fc 0x0032fa54: 80040154 00000000 0032faf4 00000000 0x0032fa64: 00000000 00000000 7b835a2a 00000000 Backtrace: =>0 0x7b835a72 in kernel32 (+0x25a72) (0x0032fa78) 1 0x6858459c _CxxThrowException+0x3b() in msvcrt (0x0032faa8) 2 0x0051ba78 in otdr (+0x11ba77) (0x0032fac8) 3 0x004b1aed in otdr (+0xb1aec) (0x80040154) 0x7b835a72: subl $4,%esp Modules: Module Address Debug info Name (91 modules) PE 330000- 39c000 Deferred printotdr PE 3a0000- 3fb000 Deferred exec17 PE...

...ils about the crash: > > I was able to repro the issue simply by modifying the Fibonacci example to > call an external C++ function which throws an exception, much like in > ExceptionsDemo.cpp: works on 32 bits but not on 64 bits Visual Studio. The > crash happens within Windows' _cxxThrowException routine. I read that the 64 > bits exception handling in Windows is doing some unwinding in a different > fashion than on 32 bits (as explained > here: http://lackingrhoticity.blogspot.ca/2011/11/stack-unwinding-risks-on-64-bit-windows.html). > In particular, this blog seems to state th...

...that we post our problem to this mailing list, and that perhaps Reid Kleckner and/or other people here may have some hints. Any ideas would be highly appreciated! In our case the RaiseException API function does not find the correct catch pad, which may be caused by a ThrowInfo structure handed to _CxxThrowException being empty. Apart from getting this right, is there anything else we possibly miss? Windows API functions to be called for registering catch pads or so? Some more details: We're using Clang for compiling C++ code at runtime and the ORC libraries to load and execute it in our application, whic...

...00001 00000000 7b844cd0 0x0032f810: 00000003 19930520 0032f894 00376230 0x0032f820: 0032f89c 00000007 00000000 7eaf94a4 0x0032f830: 0032f868 00300039 0037002d 00330042 0x0032f840: 002d0036 00310031 00320044 0042002d Backtrace: =>1 0x7b844d46 in kernel32 (+0x24d46) (0x0032f854) 2 0x7e8b6f0c _CxxThrowException+0x3c() in msvcrt (0x0032f884) 3 0x0035fa36 in streamio (+0x2fa36) (0x0032f8a4) 4 0x0035f82b in streamio (+0x2f82b) (0x0032f8fc) 5 0x0033ca5b in streamio (+0xca5b) (0x0032fe6c) 6 0x00526760 in game (+0x126760) (0x0032ff08) 7 0x7b877567 in kernel32 (+0x57567) (0x0032ffe8) 8 0xb7f489e7 win...

...verified that the CTRL/C handler works, as does > > > the stack trace. In fact, here's a sample: > > > > > > 77E73887 (0xE06D7363 0x00000001 0x00000003 0x0012FF28), RaiseException()+0080 bytes(s) > > > 10226DB9 (0x0012FF44 0x0040DEFC 0x00020024 0x00647373), _CxxThrowException()+0057 bytes(s) > > > 00401822 (0x0012FFC0 0x00409A2C 0x00000001 0x003250D0), XYZ::func()+0034 bytes(s), c:\projects\llvm\test.cpp, line 12 > > > 004017ED (0x00000001 0x003250D0 0x00322C68 0x00020024), main()+0013 bytes(s), c:\projects\llvm\test.cpp, line 19 > > > 00409A2...

...7b841df0 00000003 0x0034d7b4: 19930520 0034d848 5f4b3f50 001578f0 0x0034d7c4: bafa4a38 00110000 0034d810 0014d984 0x0034d7d4: 7bc3338f ffffffff 7bc896bc 0034d830 0x0034d7e4: 7bc42135 00110048 ffffff06 0034d820 Backtrace: =>1 0x7b841e83 RaiseException+0x93() in kernel32 (0x0034d808) 2 0x7e893a1e _CxxThrowException+0x3e() in msvcrt (0x0034d838) 3 0x5f453a11 1266() in mfc42 (0x0034d84c) 4 0x5f45a66d in mfc42 (+0x5a66d) (0xbafa4a00) 5 0x00000000 (0x00000000) 0x7b841e83 RaiseException+0x93 in kernel32: subl $4,%esp Modules: Module Address Debug info Name (98 modules) PE 350000- 362000 Deferred zlib1 PE 400000- 5...

Patch looks good so I committed it. I'd be interested in knowing what your test results are once you start testing with the Win32 port. Reid. On Sat, 2004-09-18 at 12:01, Jeff Cohen wrote: > Here's my first take on Path.cpp. It has a few holes still but it ought > to be basically functional. > > A few observations: > > First, the Win32 version still has a lot of code

We already have something like what you describe in the form of mingw support. It runs on Windows and handles exceptions using a DWARF-style personality function and (I think) an LLVM-provided implementation of the libc++abi library. What this doesn't do is provide interoperability with MSVC-compiled objects. For instance, you can't throw an exception from MSVC-compiled code and catch

....base*)* %25 to i64 call void @__llvm_profile_instrument_target(i64 %26, i8* bitcast ({ i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @"__profd_?run at test@@QEAAXPEAVbase@@H at Z" to i8*), i32 0) call void %25(%class.base* %1) [ "funclet"(token %20) ] call void @_CxxThrowException(i8* null, %eh.ThrowInfo* null) #15 [ "funclet"(token %20) ] unreachable Following this pass, this IR has been replaced with the following, causing a breakage to the original program. This is occurring because the instrumentation function call, "__llvm_profile_instrumen...

Here's my first take on Path.cpp. It has a few holes still but it ought to be basically functional. A few observations: First, the Win32 version still has a lot of code in common with Unix. This code should be pulled out into a common file. Second, some of the functions leave me scratching me head. What purpose does create_file serve? Is there really a need to create empty files? (It

...call void @__llvm_profile_instrument_target(i64 %26, i8* bitcast ({ > i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @"__profd_?run at test > @@QEAAXPEAVbase@@H at Z" to i8*), i32 0) > call void %25(%class.base* %1) [ "funclet"(token %20) ] > call void @_CxxThrowException(i8* null, %eh.ThrowInfo* null) #15 [ > "funclet"(token %20) ] > unreachable > > Following this pass, this IR has been replaced with the following, > causing a breakage to the original program. This is occurring because the > instrumentation function call, &quot...

...?$char_traits at D@std@@V?$allocator at D@2@@http at beast@boost@@V?$basic_fields at V?$allocator at D@std@@@234@@http at beast@1 at AEAUsend_lambda@server_session@@PEBD3 at Z@4HA))​ ​ lld-link: warning: C:\Users\Osman\AppData\Local\Temp\currency_converter-264ae1.o: locally defined symbol imported: _CxxThrowException (defined in libvcruntime.lib(throw.obj)) [LNK4217]​ lld-link: error: undefined symbol: "class boost::system::error_category const & __cdecl boost::system::detail::system_category_ncx(void)" (?system_category_ncx at detail@system at boost@@YAAEBVerror_category at 23@XZ)​ >>> r...

...very .lib and .obj provided by Visual > Studio, I get an assertion failure with "Relocation type not implemented > yet!". RuntimeDyldCOFF is missing a lot of relocation support. We need a COFF expert to fix that and unfortunately I'm not one. I decided to have a look at "_CxxThrowException". I inserted my own > function for the JIT and had a look at the parameters. I got two of them. > The first was the address of the Exception-Object, which was correct. The > second is the address for the "_ThrowInfo". This address was valid too, but > all its members - ex...

...1fc3c4b 0x7fcbfc2c: c0000005 70201704 7fcbfc7c 70193b1d 0x7fcbfc3c: c0000005 00000000 00000000 00000000 0x7fcbfc4c: 7fcbfc60 7e530000 000003e8 77fb2524 0200: sel=1007 base=7befc000 limit=00001fff 32-bit rw- Backtrace: =>1 0x70190bd5 RaiseException+0x7e in kernel32 (0x7fcbfc60) 2 0x77f8b544 _CxxThrowException+0x48 in msvcrt (0x7fcbfc88) fixme:dbghelp:sffip_cb NIY on 'C:\Xpat32\XpatFC\DebugDll\XpatFCd.pdb' 3 0x10011492 in xpatfcd (+0x11492) (0x7fcbfca0) fixme:dbghelp:sffip_cb NIY on 'C:\XPAT32\MemDump\Debug\ScrDump.pdb' 4 0x6d611e8f EffectProcs+0xe80 in scrdump (0x7fcbfd4c) fixme:db...

...tor at D@2@@http at beast@boost@@V? > $basic_fields at V?$allocator at D@std@@@234@@http at beast@1 at AEAUsend_lambda@server_ > session@@PEBD3 at Z@4HA))​ > ​ > lld-link: warning: > C:\Users\Osman\AppData\Local\Temp\currency_converter-264ae1.o: locally > defined symbol imported: _CxxThrowException (defined in > libvcruntime.lib(throw.obj)) [LNK4217]​ > lld-link: error: undefined symbol: "class > boost::system::error_category const & __cdecl > boost::system::detail::system_category_ncx(void)" > (?system_category_ncx at detail@system at boost@@YAAEBVerror_category...

...> > $basic_fields at V?$allocator at D@std@@@234@@http at beast@1 at AEAUsend_lambda > @server_ > > session@@PEBD3 at Z@4HA))​ > > ​ > > lld-link: warning: > > C:\Users\Osman\AppData\Local\Temp\currency_converter-264ae1.o: locally > > defined symbol imported: _CxxThrowException (defined in > > libvcruntime.lib(throw.obj)) [LNK4217]​ > > lld-link: error: undefined symbol: "class > > boost::system::error_category const & __cdecl > > boost::system::detail::system_category_ncx(void)" > > (?system_category_ncx at detail@system at boo...