Untrappable crash .. where to look?

I have a routine which crashes instantly without getting to any exception handler, only when compiled and only in the 64 bit compiled version.
Its a routine which opens a picture from disc, creates a thumbnail version of it, saves the big picture to a global variable, and saves the thumbnail into an XML document using picturetostring

The routine runs to about 200 lines and the crash seems to happen at ‘some point’ along the way
I added many writelog entries to see if I could spot ‘the line’ where it crashes but its different each time.
There must be a memory issue.

Sometimes it just works.. same steps, same picture.

The crash log that appears in console can vary but most often ends like this:

0 libsystem_kernel.dylib 0x00007fffa54ef0aa __abort_with_payload + 10
1 libsystem_kernel.dylib 0x00007fffa54eb326 abort_with_payload_wrapper_internal + 90
2 libsystem_kernel.dylib 0x00007fffa54eb2cc abort_with_reason + 22
3 libobjc.A.dylib 0x00007fffa4add1b2 _objc_fatalv(unsigned long long, unsigned long long, char const*, __va_list_tag*) + 102
4 libobjc.A.dylib 0x00007fffa4add04d _objc_fatal(char const*, …) + 154
5 libobjc.A.dylib 0x00007fffa4ae7f8a (anonymous namespace)::AutoreleasePoolPage::busted(bool) + 144
6 libobjc.A.dylib 0x00007fffa4ad039e (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 750
7 com.apple.CoreFoundation 0x00007fff8fbf2026 _CFAutoreleasePoolPop + 22
8 com.apple.Foundation 0x00007fff9163ab57 -[NSAutoreleasePool drain] + 146
9 com.apple.AppKit 0x00007fff8d721482 -[NSApplication run] + 1093
10 com.xojo.XojoFramework 0x0000000107d2bafb RuntimeRun + 44[/quote]

Does that give anyone a hint as to what is happening?

Xojo 2015R3 compiled app to 64bit

Are both the big picture and thumbnail dimensions multiples of 4?

64-bit compilation was not very stable back at 2015r3. I would suggest trying it with 2018r1.1 and see. You can run it in the IDE without upgrading to that version.

Runs in the 2017 debugger fine under 64bit, and everything fine in 32bit.
And the images are multiples of 4 in width

Im so reluctant to upgrade… 2018 has more bugs than 2015 (at least on Windows) and a pile of stuff I don’t need.
If I upgrade to 2018, a saved project isn’t openable in earlier versions either. Thats bad.
I can see myself ‘upgrading’ and then finding I don’t get any benefit from it, or actually suffer from the change.

Seriously don’t use 2015 for 64bit. Use a VM for testing or another computer. Check out a branch from SVN or whatever.

Do you know what an AutoReleasePool is? Try to give your code a bit more time by doing small amounts of sleep. Or try the MBS plugin with something similar to:

if AutoCounter mod 50 = 0 then AutoReleasePool = nil AutoReleasePool = new NSAutoreleasePoolMBS DelayMBS 1 end if

I have to echo the sentiment of not using 64-bit with 2015r3. There were a huge number of major bugs fixed in 64-but support between then and when 64-bit was taken out of beta.

OK - slightly off topic then, but -
Is it possible to buy a licence for 2017 even though 2018 is out?
Is it possible to save a project from 2018 that can be opened in 2015 afterwards?
If I buy a new licence and it makes no difference does the 30day period apply?

(I appreciate that as a very long time user, I should embrace ‘the latest version’ but sadly I’ve waited years for a release to appear which just fixes things without additionally breaking something important that I rely on.
I had big hopes for 2018 - but what I hear is the windows version is very much slower after an attempt to reduce the flicker, and that printing is problematic)

@Beatrix: Actually, no, I dont know what the AutoReleasePool is.
Id guess it refers to the method by which Xojo releases memory it has allocated for something.
I’d be happy to try the delay here, but Im not sure where it would be best placed - at the end of the method, maybe?

It’s better if you ask the Xojo persons your license questions directly.

You do have SVN or Git, right? And if not, now is the time to invest in this. And it’s quite possible that after saving in 2018 you screw up your project for 2015.

Xojo’s memory management is by reference counting. You don’t have a reference anymore and Xojo will purge it from memory. The underlying Cocoa has a different memory management called garbage collection. As far as I understand they have been moving away from this in the last years. There the objects that aren’t needed anymore are purged in groups by the garbage collector. I only know for sure that when I do a lot of Cocoa operations (AppleScript) with the MBS plugin I need to do this manually after 50/100 runs or so. Or the memory goes up and up. I haven’t needed this for pure Xojo code before.

I see. Thanks
Looks like AutoRelease is for threads any way… pretty sure I dont have any running here.

The most common cause of an issue like this is either releasing a NS/CFObject more times than needed or marking an NS/CFObject for AutoRelease more than once.

Do you have any declares in your application? If so, take a look at them.

autoRelease is one of the things that if used correctly, works fine, but is so easy to use incorrectly, that I would advise most people to simply avoid it for the time being.

No declares here.

The code is a bit specifc and 'makes use of classes and variables which are declared at a non-local level) to post here ,
but since it works sometimes, and sometimes it gets called 2 or 3 times before going bink, my money is on a memory management issue.
Everything in this section of code is ‘something I do elsewhere’ too, apart from

But commenting those lines out doesnt affect it.

I bought a licence to get me into 2017.
Compiled to 64 bit , no code changed, and it seems to be working properly (ie the way it did in 32bit)
Thats a relief.
Now to try and test everthing else … :wink: