crash in QMLManager destructor
Hi again So it seems like the crash happening on close on iOS is line 608 in qmlmanager.cpp - so at the end of the QMLManager destructor. Thread 0 name: Thread 0 Crashed: 0 libsystem_kernel.dylib 0x0001d563101c __pthread_kill + 8 (:-1) 1 libsystem_pthread.dylib 0x0001f7b7d680 pthread_kill + 268 (pthread.c:1681) 2 libsystem_c.dylib 0x000196191b90 abort + 180 (abort.c:118) 3 libc++abi.dylib 0x0001f7aaa660 abort_message + 132 (abort_message.cpp:78) 4 libc++abi.dylib 0x0001f7a9a62c demangling_terminate_handler() + 348 (cxa_default_handlers.cpp:77) 5 libobjc.A.dylib 0x00018652ad34 _objc_terminate() + 144 (objc-exception.mm:496) 6 libc++abi.dylib 0x0001f7aa9a24 std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59) 7 libc++abi.dylib 0x0001f7aa99c8 std::terminate() + 56 (cxa_handlers.cpp:88) 8 Subsurface-mobile 0x00010027589c QMLManager::~QMLManager() + 68 (qmlmanager.cpp:608) 9 Subsurface-mobile 0x0001001620e4 QQmlPrivate::QQmlElement::~QQmlElement() + 12 (qqmlprivate.h:144) 10 Subsurface-mobile 0x0001001620e4 QQmlPrivate::QQmlElement::~QQmlElement() + 12 (qqmlprivate.h:142) 11 Subsurface-mobile 0x0001001620e4 QQmlPrivate::QQmlElement::~QQmlElement() + 28 (qqmlprivate.h:142) 12 Subsurface-mobile 0x000101759b08 QObjectPrivate::deleteChildren() + 260 13 Subsurface-mobile 0x000101759844 QObject::~QObject() + 1968 14 Subsurface-mobile 0x000100d9e4e8 QQuickItem::~QQuickItem() + 984 15 Subsurface-mobile 0x000100c9d45c QQuickContentItem::~QQuickContentItem() + 12 16 Subsurface-mobile 0x000101759b08 QObjectPrivate::deleteChildren() + 260 17 Subsurface-mobile 0x000101759844 QObject::~QObject() + 1968 18 Subsurface-mobile 0x000100d9e4e8 QQuickItem::~QQuickItem() + 984 19 Subsurface-mobile 0x000100dcce68 QQuickRootItem::~QQuickRootItem() + 12 20 Subsurface-mobile 0x000100dc0fec QQuickWindow::~QQuickWindow() + 216 21 Subsurface-mobile 0x000100be2b8c QQmlPrivate::QQmlElement::~QQmlElement() + 56 22 Subsurface-mobile 0x0001014939bc QQmlApplicationEngine::~QQmlApplicationEngine() + 168 23 Subsurface-mobile 0x00010016153c run_mobile_ui(double) + 3468 (subsurface-helper.cpp:190) 24 Subsurface-mobile 0x000100160330 main + 816 (subsurface-mobile-main.cpp:95) 25 Subsurface-mobile 0x00010061bb50 user_main_trampoline() + 280 26 Subsurface-mobile 0x00010061b990 +[QIOSApplicationStateTracker applicationDidFinishLaunching:] + 1120 27 ??? 0x0002 0x0 + 2 That's of course a bit frustrating (because that thing's a monster), but it may help us to track down what's going on. Of course, sadly, the number of Qt / QML experts in the developer team has dwindled quite a bit. And our C++ rock star developer is crazy busy at his day job. So I'm not sure how much hope I have that this can be fixed, quickly. It looks to me like we are reasonably walking down the stack of objects, trying to destroy/free them, and then things go poorly. In run_mobile_ui (stack frame 23) we have finished the app; qApp->exec() has returned and it now starts cleaning up the local objects. And the QMLApplicationEngine that owns the QML app just walks down it's objects... Of course, since we have completed the app, I really don't think I care all that much - but I still don't want things to crash. That's ugly. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
Hi Dirk, On Montag, 8. Jänner 2024 18:10:45 CET Dirk Hohndel via subsurface wrote: > So it seems like the crash happening on close on iOS is line 608 in > qmlmanager.cpp - so at the end of the QMLManager destructor. This doesn't happen for me (mobile-on-desktop), so I'm not sure that I can help. Can you send me the disassembly of QMLManager::~QMLManager()? E.g. in gdb: "disassemble QMLManager::~QMLManager()" Note that for me that doesn't give the actual function, but only a stub: Dump of assembler code for function _ZN10QMLManagerD0Ev: 0x0014b1e0 <+0>: endbr64 0x0014b1e4 <+4>: push %rbx 0x0014b1e5 <+5>: mov%rdi,%rbx 0x0014b1e8 <+8>: call 0x14af80 <_ZN10QMLManagerD2Ev> 0x0014b1ed <+13>:mov%rbx,%rdi 0x0014b1f0 <+16>:mov$0xf8,%esi 0x0014b1f5 <+21>:pop%rbx 0x0014b1f6 <+22>:jmp0x104510 <_ZdlPvm@plt> End of assembler dump. The actual function is then in 0x14af80, for whatever reason. Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
> On Jan 8, 2024, at 10:29, Berthold Stoeger wrote: > > Hi Dirk, > > On Montag, 8. Jänner 2024 18:10:45 CET Dirk Hohndel via subsurface wrote: > > > So it seems like the crash happening on close on iOS is line 608 in > > qmlmanager.cpp - so at the end of the QMLManager destructor. > > This doesn't happen for me (mobile-on-desktop), so I'm not sure that I can > help. Can you send me the disassembly of QMLManager::~QMLManager()? > > E.g. in gdb: "disassemble QMLManager::~QMLManager()" Note that for me that > doesn't give the actual function, but only a stub: > > Dump of assembler code for function _ZN10QMLManagerD0Ev: >0x0014b1e0 <+0>: endbr64 >0x0014b1e4 <+4>: push %rbx >0x0014b1e5 <+5>: mov%rdi,%rbx >0x0014b1e8 <+8>: call 0x14af80 <_ZN10QMLManagerD2Ev> >0x0014b1ed <+13>:mov%rbx,%rdi >0x0014b1f0 <+16>:mov$0xf8,%esi >0x0014b1f5 <+21>:pop%rbx >0x0014b1f6 <+22>:jmp0x104510 <_ZdlPvm@plt> > End of assembler dump. > > The actual function is then in 0x14af80, for whatever reason. Now I need to figure out how to do that in Xcode ... Hmmm. Can't find an obvious way when I open the stack trace. It just shows the C++ code. Online I find suggestions how to do that when live-debugging an app on an iOS device. So I guess I DO need to try and reproduce this on my iPad. So far I wasn't able to... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Montag, 8. Jänner 2024 19:35:56 CET Dirk Hohndel wrote: > Hmmm. Can't find an obvious way when I open the stack trace. It just shows > the C++ code. Does this help: https://discussions.apple.com/thread/2423113 ? > Online I find suggestions how to do that when live-debugging > an app on an iOS device. So I guess I DO need to try and reproduce this on > my iPad. So far I wasn't able to... You shouldn't have to hit the bug to disassemble the function. In the worst case, you could set a setpoint in QMLManager::~QMLManager, isn't it? If all else fails, you could disassemble qmlmanager.ccc.o. as such: objdump -d ./mobile-widgets/CMakeFiles/subsurface_mobile.dir/qmlmanager.cpp.o (at least that's how it works on Linux, assuming it is similar for Apple) and we could try to look from there... Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Monday, 8 January 2024 14:10:45 -03 Dirk Hohndel via subsurface wrote: > 7 libc++abi.dylib 0x0001f7aa99c8 std::terminate() > + 56 (cxa_handlers.cpp:88) 8 Subsurface-mobile > 0x00010027589c QMLManager::~QMLManager() + 68 (qmlmanager.cpp:608) The fact that it's spelt "QML" in all caps in the class name led me to find this file in Subsurface's sources. Line 608 is the closing bracket of the destructor, which definitely raises a WTF question: why is it calling std::terminate()? Since there's nothing in the source code for that to call it directly, that implies it's debugging or hardening code inserted by the compiler itself. As it's happening on the closing brace, it's probably QMLManager trying to destroy one of its member variables. The one thing that comes to mind is an exception. Throwing in destructors is really frowned upon (you can't fail to clean up) and by default all destructors are noexcept, so trying to throw from them causes an immediate std::terminate(). If this is the case, then the question is: what is throwing? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Montag, 8. Jänner 2024 21:17:19 CET Dirk Hohndel wrote: > > If all else fails, you could disassemble qmlmanager.ccc.o. as such: > > > > objdump -d > > ./mobile-widgets/CMakeFiles/subsurface_mobile.dir/qmlmanager.cpp.o (at > > least that's how it works on Linux, assuming it is similar for Apple) > > > > and we could try to look from there... > > That's what I did. Sorry, that code makes little sense to me. It is the first time that I see ARM64 code, but it seems to me that symbol information is missing - all these '9400' look like place holders. Could you perhaps give the assembly output generated by the compiler (add -S to the compiler flags and replace "-o *.o" by "-o *.s")? Subobjects are destructed in reverse order, so seeing where the call to std::terminate() is should give a good idea which object is the culprit. Does clang not give a warning? Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Montag, 8. Jänner 2024 21:51:39 CET Berthold Stoeger via subsurface wrote: > On Montag, 8. Jänner 2024 21:17:19 CET Dirk Hohndel wrote: > > > If all else fails, you could disassemble qmlmanager.ccc.o. as such: > > > > > > objdump -d > > > ./mobile-widgets/CMakeFiles/subsurface_mobile.dir/qmlmanager.cpp.o (at > > > least that's how it works on Linux, assuming it is similar for Apple) > > > > > > and we could try to look from there... > > > > That's what I did. > > Sorry, that code makes little sense to me. It is the first time that I see > ARM64 code, but it seems to me that symbol information is missing - all > these '9400' look like place holders. If the " QMLManager::~QMLManager() + 68" in your first e-mail is correct, it seems to be right at the beginning of the destructor (for me that is right between the first to bl instructions). Which means that it is probably the last or second to last subobject. I suggest removing the "IosShare iosshare" thing and see if that is it. Could also be the "QFile appLogFile". Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Mon, 8 Jan 2024 at 12:18, Dirk Hohndel via subsurface wrote: > On Jan 8, 2024, at 11:15, Berthold Stoeger wrote: > > > > If all else fails, you could disassemble qmlmanager.ccc.o. as such: > > > > objdump -d > > ./mobile-widgets/CMakeFiles/subsurface_mobile.dir/qmlmanager.cpp.o\ "objdump -d" is horrible at disassembly. For some unfathomable reason, it doesn't look at relocation information, so when it disassembles any instruction with relocations, the end result is garbage. And no, adding "-r" to make it show relocation information isn't much better. The disassembly is still garbage, but there will now be an extra line that basically says "if I wasn't showing you garbage, I would use this line to tell you what the garbage should have been". So then you can - manually - use that relocation information to show what the disassembly should have been. > That's what I did. > > Sorry for the LONG email :) > > 5d38 : > 5d38: a9bd57f6 stp x22, x21, [sp, #-48]! > 5d3c: a9014ff4 stp x20, x19, [sp, #16] > 5d40: a9027bfd stp x29, x30, [sp, #32] > 5d44: 910083fd add x29, sp, #32 > 5d48: aa0003f3 mov x19, x0 > 5d4c: 9008 adrp x8, 0x5000 > 5d50: f9400108 ldr x8, [x8] > 5d54: 91004108 add x8, x8, #16 > 5d58: f908 str x8, [x0] > 5d5c: 39442008 ldrb w8, [x0, #264] > 5d60: 3468 cbz w8, 0x5d6c > 5d64: 9103e260 add x0, x19, #248 > 5d68: 9400 bl 0x5d68 > 5d6c: 9008 adrp x8, 0x5000 > 5d70: f900011f str xzr, [x8] > 5d74: 91044260 add x0, x19, #272 > 5d78: 9400 bl 0x5d78 > 5d7c: 9103e260 add x0, x19, #248 > 5d80: 9400 bl 0x5d80 > 5d84: f9407a60 ldr x0, [x19, #240] > 5d88: b948 ldr w8, [x0] Well, that > 5d7c: 9103e260 add x0, x19, #248 is the call chain result from here: 8 Subsurface-mobile 0x00010027589c QMLManager::~QMLManager() + 68 (qmlmanager.cpp:608) but that's really just the return point from that > 5d78: 9400 bl 0x5d78 and that's very much an example of the whole "objdump is showing garbage". That function isn't calling itself, but that's what objdump -d shows, because it doesn't look at the reloc info. Anyway, I think this has probably been compiled with some sanitizer. With "-r" to objdump, at least we'd see what the call target for that "bl" instruction is, which might give some clue. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
> On Jan 8, 2024, at 13:04, Linus Torvalds wrote: > > On Mon, 8 Jan 2024 at 12:18, Dirk Hohndel via subsurface > wrote: > > "objdump -d" is horrible at disassembly. no kidding. > For some unfathomable reason, it doesn't look at relocation > information, so when it disassembles any instruction with relocations, > the end result is garbage. > > And no, adding "-r" to make it show relocation information isn't much > better. The disassembly is still garbage, but there will now be an > extra line that basically says "if I wasn't showing you garbage, I > would use this line to tell you what the garbage should have been". > > So then you can - manually - use that relocation information to show > what the disassembly should have been. see below > is the call chain result from here: > > 8 Subsurface-mobile 0x00010027589c > QMLManager::~QMLManager() + 68 (qmlmanager.cpp:608) > > but that's really just the return point from that > >>5d78: 9400 bl 0x5d78 > > and that's very much an example of the whole "objdump is showing > garbage". That function isn't calling itself, but that's what objdump > -d shows, because it doesn't look at the reloc info. > > Anyway, I think this has probably been compiled with some sanitizer. > With "-r" to objdump, at least we'd see what the call target for that > "bl" instruction is, which might give some clue. 5d60: 3468 cbz w8, 0x5d6c 5d64: 9103e260 add x0, x19, #248 5d68: 9400 bl 0x5d68 5d68: ARM64_RELOC_BRANCH26 __ZN11QFileDevice5closeEv 5d6c: 9008 adrpx8, 0x5000 5d6c: ARM64_RELOC_PAGE21 __ZN10QMLManager10m_instanceE 5d70: f900011f str xzr, [x8] 5d70: ARM64_RELOC_PAGEOFF12 __ZN10QMLManager10m_instanceE 5d74: 91044260 add x0, x19, #272 5d78: 9400 bl 0x5d78 5d78: ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev 5d7c: 9103e260 add x0, x19, #248 5d80: 9400 bl 0x5d80 5d80: ARM64_RELOC_BRANCH26 __ZN5QFileD1Ev ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Montag, 8. Jänner 2024 22:15:24 CET Dirk Hohndel wrote: > > On Jan 8, 2024, at 13:04, Linus Torvalds wrote: > > > > On Mon, 8 Jan 2024 at 12:18, Dirk Hohndel via subsurface > > wrote: > > > > "objdump -d" is horrible at disassembly. > > no kidding. Yes, I was also disappointed. :) > 5d60: 3468 cbz w8, 0x5d6c > 5d64: 9103e260 add x0, x19, #248 > 5d68: 9400 bl 0x5d68 > 5d68: ARM64_RELOC_BRANCH26 > __ZN11QFileDevice5closeEv 5d6c: 9008 adrpx8, 0x5000 > 5d6c: ARM64_RELOC_PAGE21 > __ZN10QMLManager10m_instanceE 5d70: f900011f str xzr, [x8] > 5d70: ARM64_RELOC_PAGEOFF12 > __ZN10QMLManager10m_instanceE 5d74: 91044260 add x0, x19, #272 > 5d78: 9400 bl 0x5d78 > 5d78: ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev Destructor of IosShare. > 5d7c: 9103e260 add x0, x19, #248 > 5d80: 9400 bl 0x5d80 > 5d80: ARM64_RELOC_BRANCH26 __ZN5QFileD1Ev Destructor of QFile. Seems to be one of the two. Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Mon, 8 Jan 2024 at 13:15, Dirk Hohndel wrote: > > > > So then you can - manually - use that relocation information to show > > what the disassembly should have been. > > see below Lovely. It doesn't even do the C++ demangling without using '-C'. Whatever. > 5d60: 3468 cbz w8, 0x5d6c > 5d64: 9103e260 add x0, x19, #248 > 5d68: 9400 bl 0x5d68 > 5d68: ARM64_RELOC_BRANCH26 > __ZN11QFileDevice5closeEv > 5d6c: 9008 adrpx8, 0x5000 > 5d6c: ARM64_RELOC_PAGE21 > __ZN10QMLManager10m_instanceE > 5d70: f900011f str xzr, [x8] > 5d70: ARM64_RELOC_PAGEOFF12 > __ZN10QMLManager10m_instanceE > 5d74: 91044260 add x0, x19, #272 > 5d78: 9400 bl 0x5d78 > 5d78: ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev Ok, so this is the call that then blows up. I assume the demangled name is "IosShare", but you can verify that with objdump -drC which presumably gives _amost_ usable disassembly. And yeah, don't ask me why the objdump defaults are that incomprehensible, and why - even with "please do relocations and demangling" it ends up doing it with that ugly two-line format. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Montag, 8. Jänner 2024 22:15:24 CET Dirk Hohndel wrote: > 5d78: ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev Could you show the disassembly of that? Perhaps a tail-call to std::terminate and therefore it doesn't show up in the stack trace? Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
> On Jan 8, 2024, at 13:20, Berthold Stoeger wrote: > > On Montag, 8. Jänner 2024 22:15:24 CET Dirk Hohndel wrote: > > > 5d78: ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev > > Could you show the disassembly of that? Perhaps a tail-call to std::terminate > and therefore it doesn't show up in the stack trace? > of course IosShare is that lovely ObjC++ thing that I did in response to stuff I found on the Qt Forum. And I most definitely did that blind because I can't even read that code and fully make sense of it... Thiago, is that something that makes sense to you? here's the disassembled code and yes, it does call terminate... 0070 : 70: a9be4ff4 stp x20, x19, [sp, #-32]! 74: a9017bfd stp x29, x30, [sp, #16] 78: 910043fd add x29, sp, #16 7c: aa0003f3 mov x19, x0 80: f940 ldr x0, [x0] 84: 9400 bl 0x84 0084: ARM64_RELOC_BRANCH26 _objc_msgSend$dealloc 88: aa1303e0 mov x0, x19 8c: a9417bfd ldp x29, x30, [sp, #16] 90: a8c24ff4 ldp x20, x19, [sp], #32 94: d65f03c0 ret 98: 9400 bl 0x98 0098: ARM64_RELOC_BRANCH26 ___clang_call_terminate ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
> On Jan 8, 2024, at 13:26, Dirk Hohndel wrote:
>
>
>
>> On Jan 8, 2024, at 13:20, Berthold Stoeger wrote:
>>
>> On Montag, 8. Jänner 2024 22:15:24 CET Dirk Hohndel wrote:
>>
>>>5d78: ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev
>>
>> Could you show the disassembly of that? Perhaps a tail-call to
>> std::terminate and therefore it doesn't show up in the stack trace?
>>
>
> of course IosShare is that lovely ObjC++ thing that I did in response to
> stuff I found on the Qt Forum. And I most definitely did that blind because I
> can't even read that code and fully make sense of it...
>
> Thiago, is that something that makes sense to you?
>
> here's the disassembled code and yes, it does call terminate...
>
> 0070 :
> 70: a9be4ff4 stp x20, x19, [sp, #-32]!
> 74: a9017bfd stp x29, x30, [sp, #16]
> 78: 910043fd add x29, sp, #16
> 7c: aa0003f3 mov x19, x0
> 80: f940 ldr x0, [x0]
> 84: 9400 bl 0x84
>0084: ARM64_RELOC_BRANCH26 _objc_msgSend$dealloc
> 88: aa1303e0 mov x0, x19
> 8c: a9417bfd ldp x29, x30, [sp, #16]
> 90: a8c24ff4 ldp x20, x19, [sp], #32
> 94: d65f03c0 ret
> 98: 9400 bl 0x98
>0098: ARM64_RELOC_BRANCH26 ___clang_call_terminate
>
which of course (snort) is this:
IosShare::~IosShare() {
[(id)self dealloc];
}
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
> On Jan 8, 2024, at 13:28, Dirk wrote:
>
>
> IosShare::~IosShare() {
> [(id)self dealloc];
> }
Test build with empty destructor coming up. Of course I never know how long
Apple will sit on it before it shows up in TestFlight.
/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Montag, 8. Jänner 2024 22:26:46 CET Dirk Hohndel wrote: > > On Jan 8, 2024, at 13:20, Berthold Stoeger wrote: > > > > On Montag, 8. Jänner 2024 22:15:24 CET Dirk Hohndel wrote: > > > 5d78: ARM64_RELOC_BRANCH26 > > > __ZN8IosShareD1Ev > > > > Could you show the disassembly of that? Perhaps a tail-call to > > std::terminate and therefore it doesn't show up in the stack trace? > of course IosShare is that lovely ObjC++ thing that I did in response to > stuff I found on the Qt Forum. And I most definitely did that blind because > I can't even read that code and fully make sense of it... > > Thiago, is that something that makes sense to you? > > here's the disassembled code and yes, it does call terminate... Does it? At least not directly as far as I can see. I reckon this is the exception handler? > 0070 : > 70: a9be4ff4 stp x20, x19, [sp, #-32]! > 74: a9017bfd stp x29, x30, [sp, #16] > 78: 910043fd add x29, sp, #16 > 7c: aa0003f3 mov x19, x0 > 80: f940 ldr x0, [x0] > 84: 9400 bl 0x84 > 0084: ARM64_RELOC_BRANCH26 > _objc_msgSend$dealloc 88: aa1303e0 mov x0, x19 > 8c: a9417bfd ldp x29, x30, [sp, #16] > 90: a8c24ff4 ldp x20, x19, [sp], #32 > 94: d65f03c0 ret > 98: 9400 bl 0x98 > 0098: ARM64_RELOC_BRANCH26 > ___clang_call_terminate Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Mon, 8 Jan 2024 at 13:36, Berthold Stoeger wrote: > > > here's the disassembled code and yes, it does call terminate... > > Does it? At least not directly as far as I can see. I reckon this is the > exception handler? Yeah, that branch to ___clang_call_terminate is not in the regular code path, that is just stp x20, x19, [sp, #-32]! stp x29, x30, [sp, #16] add x29, sp, #16 mov x19, x0 ldr x0, [x0] bl _objc_msgSend$dealloc mov x0, x19 ldp x29, x30, [sp, #16] ldp x20, x19, [sp], #32 ret which is basically just that "dealloc" call (plus flame setup, save x18/x19, save old FP/LR). So that bl ___clang_call_terminate is unreachable by normal means, but presumably is there thanks to some exception handler thing, which is presumably also why the frame has been undone and this function isn't shown in the backtrace. Bad form, but hey, exception handling is messy. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Monday, 8 January 2024 18:35:56 -03 Berthold Stoeger wrote: > > Thiago, is that something that makes sense to you? > > > > > > > > here's the disassembled code and yes, it does call terminate... > > Does it? At least not directly as far as I can see. I reckon this is the > exception handler? Quite right, there's no branch instruction arriving there. So it could only be reached via stack unwinding due to an exception being thrown. I don't know Objective C or C++ at all so I can't tell for sure why dealloc would fail. The most likely condition is that the object has become corrupt, probably due to a buffer overflow somewhere or it's a double-free. The object itself appears to be a single 64-bit word in size (probably a pointer). Searching for "objective c dealloc exception" has as first result "don't use dealloc; use release"[1]. I also don't know why Clang inserted that __clang_call_terminate( here. The stack unwinding mechanism should have done that, not the IosShare destructor. In that case, the runtime usually prints the name of the exception that was thrown. Maybe building in ASan mode and running will provide some clue. [1] https://stackoverflow.com/questions/559295/difference-between-release-and-dealloc-in-objective-c > > 0070 : > > 70: a9be4ff4 stp x20, x19, [sp, #-32]! > > 74: a9017bfd stp x29, x30, [sp, #16] > > 78: 910043fd add x29, sp, #16 > > 7c: aa0003f3 mov x19, x0 > > 80: f940 ldr x0, [x0] > > 84: 9400 bl 0x84 > > 0084: ARM64_RELOC_BRANCH26 > > _objc_msgSend$dealloc > > 88: aa1303e0 mov x0, x19 > > 8c: a9417bfd ldp x29, x30, [sp, #16] > > 90: a8c24ff4 ldp x20, x19, [sp], #32 > > 94: d65f03c0 ret > > 98: 9400 bl 0x98 > > 0098: ARM64_RELOC_BRANCH26 > > ___clang_call_terminate -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
>> On Jan 8, 2024, at 13:28, Dirk wrote:
>>
>>
>> IosShare::~IosShare() {
>> [(id)self dealloc];
>> }
>
>
> Test build with empty destructor coming up. Of course I never know how long
> Apple will sit on it before it shows up in TestFlight.
I managed to beat Xcode into submission to allow me to locally debug this with
my iPad.
I first was able to reproduce the crash (thanks to those who gave detailed
explanations when it would happen).
And then removed the dealloc call and now I cannot reproduce the crash.
So I am somewhat optimistic that once the next build gets approved, we'll have
this one fixed.
Thanks for all the help tracking this down!
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
> On Jan 8, 2024, at 15:39, Dirk wrote: > > So I am somewhat optimistic that once the next build gets approved, we'll > have this one fixed. 2.5h - that's not bad at all. You should see a TestFlight notification (if you are part of the beta testers for iOS). /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Tue, 9 Jan 2024 at 13:10, Dirk Hohndel via subsurface < subsurface@subsurface-divelog.org> wrote: > > > > On Jan 8, 2024, at 15:39, Dirk wrote: > > > > So I am somewhat optimistic that once the next build gets approved, > we'll have this one fixed. > > 2.5h - that's not bad at all. > > You should see a TestFlight notification (if you are part of the beta > testers for iOS). > The new version (6.0.5031.1) fixes the crash on exit on my iPhone SE 3rd gen. Cheers, Rick ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
Success! No crash on the latest build for me. ...Hartley > On Jan 8, 2024, at 9:03 PM, Dirk Hohndel wrote: > > > >> On Jan 8, 2024, at 15:39, Dirk wrote: >> >> So I am somewhat optimistic that once the next build gets approved, we'll >> have this one fixed. > > 2.5h - that's not bad at all. > > You should see a TestFlight notification (if you are part of the beta testers > for iOS). > > /D > > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
I have confirmed as well that this fixes the crash on exit I was able to reproduce earlier today. -Doug > On Jan 8, 2024, at 6:03 PM, Dirk Hohndel via subsurface > wrote: > > > >> On Jan 8, 2024, at 15:39, Dirk wrote: >> >> So I am somewhat optimistic that once the next build gets approved, we'll >> have this one fixed. > > 2.5h - that's not bad at all. > > You should see a TestFlight notification (if you are part of the beta testers > for iOS). > > /D > > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
Thank you to all of you who tested and sent me updates, on list and off.
I decided to push this one out as the next product version. The previous one in
the AppStore was really getting fairly old.
If we find more bugs I am now once again set up to be able to fairly quickly
make updated releases ("quickly" of course being gated by the speed of Apple's
reviews).
/D
> On Jan 8, 2024, at 20:46, Doug Junkins wrote:
>
> I have confirmed as well that this fixes the crash on exit I was able to
> reproduce earlier today.
>
> -Doug
>
>> On Jan 8, 2024, at 6:03 PM, Dirk Hohndel via subsurface
>> wrote:
>>
>>
>>
>>> On Jan 8, 2024, at 15:39, Dirk wrote:
>>>
>>> So I am somewhat optimistic that once the next build gets approved, we'll
>>> have this one fixed.
>>
>> 2.5h - that's not bad at all.
>>
>> You should see a TestFlight notification (if you are part of the beta
>> testers for iOS).
>>
>> /D
>>
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
>
> Thank you to all of you who tested and sent me updates, on list and off.
>
> I decided to push this one out as the next product version. The previous one
> in the AppStore was really getting fairly old.
> If we find more bugs I am now once again set up to be able to fairly quickly
> make updated releases ("quickly" of course being gated by the speed of
> Apple's reviews).
And just over an hour later (but after I went to bed) this already has
happened. So the new version is "out in the wild" now 😁
So everyone should have access to this version.
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
