 No.13581
Osso Moderator
Feb 3, 2017, 08:53
|
Thread 1 received signal SIGSEGV, Segmentation fault. 0x00000000025c8bb2 in drc_cache::request_oob_codegen(delegate<void (unsigned char**, void*, void*)>, void*, void*) () (gdb) bt 10 #0 0x00000000025c8bb2 in drc_cache::request_oob_codegen(delegate<void (unsigned char**, void*, void*)>, void*, void*) () #1 0x00000000034be925 in drc_label_list::get_codeptr(uml::code_label, delegate<void (void*, unsigned char*)>, void*) () #2 0x00000000034bffe6 in drc::drcbe_x64::op_jmp(unsigned char*&, uml::instruction const&) () #3 0x00000000034c0482 in drc::drcbe_x64::generate(drcuml_block&, uml::instruction const*, unsigned int) () #4 0x00000000025cb490 in drcuml_block::end() () #5 0x0000000002aaa438 in ppc_device::code_compile_block(unsigned char, unsigned int) () #6 0x0000000002aab57a in ppc_device::execute_run() () #7 0x00000000036ba909 in device_scheduler::timeslice() () #8 0x00000000036769c8 in running_machine::run(bool) () #9 0x000000000208e0e8 in mame_machine_manager::execute() () |
|---|---|
 No.13687
krick Tester
Mar 9, 2017, 04:19
|
If you run the game normally (without -bench 90) and just let attract mode run, it locks up and crashes after about 70 seconds. Here's the ouput... ----------------------------------------------------- Exception at EIP=00000032000000db (register_frame_ctor+0xfa51eb0b): ACCESS VIOLATION While attempting to write memory at 00000032000000db ----------------------------------------------------- RAX=00000001000469fc RBX=000000000e538a80 RCX=0000000000227300 RDX=0000000000227300 RSI=0000000000227380 RDI=000000000e58e970 RBP=0000000000227320 RSP=00000000002272d8 R8=0000000000000003 R9=00000032000000db R10=0000000000000003 R11=000000000dfceabb R12=000000000e540380 R13=000000000dfceac5 R14=0000000000227380 R15=000000000e58e988 ----------------------------------------------------- Stack crawl: 00000000002272d0: 00000032000000db (register_frame_ctor+0xfa51eb0b) 0000000000227350: 0000000002079f27 (drc_cache::request_oob_codegen(delegate<void (unsigned char**, void*, void*)>, void*, void*)+0x00e7) 0000000000227400: 0000000002f7645d (drc_label_list::get_codeptr(uml::code_label, delegate<void (void*, unsigned char*)>, void*)+0x023d) 00000000002274b0: 0000000002f77261 (drc::drcbe_x64::op_jmp(unsigned char*&, uml::instruction const&)+0x00d1) 00000000002277e0: 0000000002f775be (drc::drcbe_x64::generate(drcuml_block&, uml::instruction const*, unsigned int)+0x01ee) 0000000000227820: 000000000207c430 (drcuml_block::end()+0x0040) 0000000000228220: 000000000254a34a (ppc_device::code_compile_block(unsigned char, unsigned int)+0x0daa) 0000000000228260: 000000000254b30c (ppc_device::execute_run()+0x006c) 0000000000228310: 0000000003160ed8 (device_scheduler::timeslice()+0x0188) 00000000002283c0: 00000000031192c8 (running_machine::run(bool)+0x0218) 000000000022f170: 0000000001b63252 (mame_machine_manager::execute()+0x0142) 000000000022f550: 0000000001bbfcc1 (cli_frontend::start_execution(mame_machine_manager*, int, char**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)+0x0ec1) 000000000022f6d0: 0000000001bc0207 (cli_frontend::execute(int, char**)+0x00a7) 000000000022f740: 0000000001b61415 (emulator_info::start_frontend(emu_options&, osd_interface&, int, char**)+0x0035) 000000000022fd80: 0000000001ab86c8 (utf8_main(int, char**)+0x0128) 000000000022fe50: 000000000368ec9c (wmain+0x018c) 000000000022ff20: 0000000000401410 (__tmainCRTStartup+0x0260) 000000000022ff50: 000000000040153b (mainCRTStartup+0x001b) 000000000022ff80: 00000000772859cd (BaseThreadInitThunk+0x000d) 000000000022ffd0: 00000000773ba561 (RtlUserThreadStart+0x0021) |
 No.13691
Phil Bennett Developer
Mar 10, 2017, 08:10
edited on: Mar 10, 2017, 08:11
|
The OOB handlers used by the DRC cache are allocated from a large 'cache' allocation that we manage ourself. However, we weren't calling placement new to construct each oob_handler object once allocated. This led to the possibility of an uninitialized pointer within the drc_oob_delegate (std::function) m_callback member whenever portions of the cache were reused, which would result in a GPFLT when m_callback was assigned. In a Clang build, I would typically see a crash in functional: template<class _Rp, class ..._ArgTypes> function<_Rp(_ArgTypes...)>::~function() { if (__f_ == (__base*)&__buf_) __f_->destroy(); else if (__f_) __f_->destroy_deallocate(); <-- here } Calling placement new after alloc seems to fix this issue. We now also explicitly call ~oob_handler before dealloc. |
 No.13692
john_iv Senior Tester
Mar 12, 2017, 05:05
|
Verified fixed w/ 2017.03.11 6:39PST build. mame0183-329-g372ac00be5 Thanks Phil - |