>
> 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
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
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
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
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
> 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
>> 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
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
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
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
> 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___
> 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
> 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
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
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
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. :)
>
> 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
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"
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
> > >
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
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
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
> 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
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
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
25 matches
Mail list logo
