Hang on first launch of an application; fine on second

Hi -
One of our customers has reported our app hangs on first launch on a particular day; on subsequent launches it’s fine.
We do have stuff which is triggered by a first run on a particular day, but there’s no stack I can use to find out what’s going wrong; instead, it’s a report as follows. Can anyone help out with understanding what’s causing this?
Built with Xojo 2015 r1.

Thread 0x230b 26 samples (1-26) priority 47 <frontmost, thread QoS user interactive, boosted, received importance donation from WindowServer [198], IO policy important> 26 start + 53 (Light Blue + 39697754) [0x25dcd5a] 1-26 26 main + 36 (Light Blue + 5848) [0x26d8] 1-26 26 _Main + 257 (Light Blue + 38656) [0xa700] 1-26 26 REALbasic._RuntimeRun + 34 (Light Blue + 2016754) [0x1ed5f2] 1-26 26 ??? (<A63A31C2-188F-39A1-BFBC-58679BBFA5FF> + 1411148) [0x2ca484c] 1-26 26 ??? (<A63A31C2-188F-39A1-BFBC-58679BBFA5FF> + 1417911) [0x2ca62b7] 1-26 26 ??? [0x99a4cb9c] 1-26 26 ??? (<A63A31C2-188F-39A1-BFBC-58679BBFA5FF> + 210543) [0x2b7f66f] 1-26 26 ??? (<A63A31C2-188F-39A1-BFBC-58679BBFA5FF> + 1417786) [0x2ca623a] 1-26 26 Application._CallFunctionWithExceptionHandling%%o<Application>p + 248 (Light Blue + 798791) [0xc4047] 1-26 26 Delegate.Invoke%% + 34 (Light Blue + 261931) [0x40f2b] 1-26 26 ??? (<A63A31C2-188F-39A1-BFBC-58679BBFA5FF> + 210758) [0x2b7f746] 1-26 26 ??? (<A63A31C2-188F-39A1-BFBC-58679BBFA5FF> + 210656) [0x2b7f6e0] 1-26 26 ??? [0x99a581e5] 1-26 26 ??? [0x99a58b41] 1-26 26 ??? [0x9acaa42c] 1-26 26 ??? [0x9acaa631] 1-26 26 ??? [0x9acaa8f8] 1-26 26 ??? [0x90f7790b] 1-26 26 ??? [0x90f77aa6] 1-26 26 ??? [0x90f78531] 1-26 26 ??? [0x9103c54f] 1-26 26 ??? [0x90fc0ab4] 1-26 26 ??? [0x90fc1006] 1-26 26 ??? [0x90fc16e6] 1-26 26 ??? [0x9a1f0863] 1-26 26 ??? [0x99de8a89] 1-26 26 ??? [0x99da4d5a] 1-26 26 ??? [0x99d9c644] 1-26 26 ??? [0x9a137e1d] 1-26 26 ??? [0x9a27e4d8] 1-26 26 ??? [0x9a27e5c8] 1-26 26 ??? [0x9a267b95] 1-26 26 ??? [0x9b0e70db] 1-26 26 ??? [0x9b079679] 1-26 26 ??? [0x9b079737] 1-26 26 ??? [0x9b0899f5] 1-26 26 ??? [0x90f475a9] 1-26 26 ??? [0x90f47672] 1-26 26 ??? [0x90f476c1] 1-26 26 ??? [0x9b08a47b] 1-26 26 ??? [0x9b0ff6cc] 1-26 26 ??? [0x9b0916b0] 1-26 26 ??? [0x98806c65] 1-26 26 ??? [0x9883660e] 1-26 26 ??? [0x964079ce] 1-26 *26 hndl_mach_scall + 216 (kernel + 2314568) [0xffffff8000435148] 1-26 *26 mach_call_munger + 373 (kernel + 2109413) [0xffffff8000402fe5] 1-26 *26 mach_msg_overwrite_trap + 205 (kernel + 1200925) [0xffffff800032531d] 1-26 *26 ipc_kmsg_send + 743 (kernel + 1133495) [0xffffff8000314bb7] 1-26 *26 ipc_mqueue_send + 529 (kernel + 1147857) [0xffffff80003183d1] 1-26 *26 thread_block_reason + 175 (kernel + 1319343) [0xffffff80003421af] 1-26 *26 ??? (kernel + 1329236) [0xffffff8000344854] 1-26 *26 machine_switch_context + 367 (kernel + 2176511) [0xffffff80004135ff] 1-26

No idea what that means, but I’d send them a version with tons of logging built in. When it happens again, they can send you the log.

I suspect that some code is putting your app into an infinite loop.

I am having that same problem with two of my apps, they are both launched as login items (Mac).
Can’t seem to find the problem.

This is only happening in Yosemite.

This happens every day with me. If yours is only happening on a particular day, is it Wednesday?

Lennox

Sounds like it’s doing something particularly intensive? I’ve seen this with hanging browser plugins that eat up CPU time and then get killed by the OS.

Hm. We’re taking a backup of stuff and doing a bunch of other things, which will indeed be intensive. I wonder if the customer’s being a little impatient, and if leaving it for a few minutes would make it come back to life…

Lennox - I’m not sure if it’s indicative but the last two times that the chap’s reported it it’s been on a Thursday…
H

[quote=203480:@Hamish Symington]Lennox - I’m not sure if it’s indicative but the last two times that the chap’s reported it it’s been on a Thursday…
H[/quote]
It was a reference to the other thread about crashing only in Wednesday’s :wink:

If your customer is being impatient perhaps you need to display a progress window before starting backups.

Sometimes letting the app start up fully and then triggering your extra work via a timer can help.

It doesn’t get it out of the main thread but it does help avoid race conditions which can occur on machines that are out of your control and in situations that are very hard to reproduce.

Race conditions are nasty and can crop up:

  • when their machine is slower than yours
  • when their machine is faster than yours
  • when their machine is doing something you have no way of detecting (like getting backed up)
  • when their machine is on a different network (from their normal use)
  • when it’s Wednesday
  • etc

You should always have a dog slow machine around your house/office/lab, for testing out situations like this. If a task takes longer an a second you need to display a progress message, preferably one giving the user some indication of how long it might take.