https://bugs.kde.org/show_bug.cgi?id=395991
--- Comment #2 from Austin English <austinengl...@gmail.com> --- 4:49:22 AM austin_laptop if someone with decent understanding of kernel32/heap.c has a few minutes, I'd appreciate if someone could help me answer Julian's questions from https://bugs.kde.org/show_bug.cgi?id=395991 (I'm happy to forward your answers if you don't have a KDE bz account) 5:01:50 AM _Marcus_ austin_laptop: so if we take a segfault, the handler would run into the expcetion chain 5:02:02 AM _Marcus_ austin_laptop: but in general, globalalloc should not fault in my opinion 5:02:54 AM _Marcus_ SetLastError(MAGIC_DEAD); 5:02:54 AM _Marcus_ hsecond = GlobalFree(LongToHandle(0xdeadbeef)); /* bogus handle */ 5:03:01 AM _Marcus_ hmm, but this code does 5:03:07 AM austin_laptop thanks _Marcus_. Yeah, from a quick read of the code, I didn't see why it would segfault, but wasn't completely sure 5:03:29 AM _Marcus_ so basically we are running into the TRY / __EXCEPT_PAGE_FAULT block in GlobalFree 5:03:37 AM _Marcus_ the testcase causes it to fault 5:03:47 AM _Marcus_ but this is our generic exceptipon handling 5:04:10 AM austin_laptop ok 5:06:40 AM _Marcus_ something in the arm signal handling is not fully correct I would think :/ 5:07:11 AM austin_laptop yeah, that's likely 5:07:36 AM austin_laptop this is armv7l rather than arm64 (and at least on VG side, is not as complete) 5:07:37 AM _Marcus_ winedebug +heap should print the ERR("invalid handle %p\n", hmem); 5:07:48 AM _Marcus_ from GlobalFree, if it does not ... we are not getting there for some reason Note: I ran with +heap, but do not get that message, so something may be broke in wine's armv7l exception handling as well. -- You are receiving this mail because: You are watching all bug changes.
