The International Simutrans Forum

 

Author Topic: 120.4.1 Crash on launch: NSRangeException  (Read 996 times)

0 Members and 1 Guest are viewing this topic.

Offline brunoresende29

  • *
  • Posts: 19
    • Personal Website
  • Languages: EN, PT
120.4.1 Crash on launch: NSRangeException
« on: January 04, 2020, 01:53:37 PM »
Hello
I'm getting a crash on launch on the latest available build on macOS. I tried looking for 121 but it doesn't seem to be available for Mac?
I'm running macOS 10.15.2 (19C57), and here is the stack trace:

Code: [Select]
2020-01-04 14:28:54.910 simutrans[70171:5061168] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 18446744073709551615 beyond bounds for empty array'
*** First throw call stack:
(
0   CoreFoundation                      0x00007fff3c05a8ab __exceptionPreprocess + 250
1   libobjc.A.dylib                     0x00007fff722cb805 objc_exception_throw + 48
2   CoreFoundation                      0x00007fff3c1098ae _CFThrowFormattedException + 202
3   CoreFoundation                      0x00007fff3bf7b3d3 -[__NSArrayM objectAtIndex:] + 142
4   simutrans                           0x000000010e641e44 _ZN10vector_tplIPK14citycar_desc_tE9insert_atEjRKS2_ + 7284
5   simutrans                           0x000000010e5e2582 _ZN10vector_tplI14halt_dist_nodeE9insert_atEjRKS0_ + 3122
6   simutrans                           0x000000010e5d078d _ZNSt3__127__insertion_sort_incompleteIRPFb14quickstone_tplI9simline_tES3_EPS3_EEbT0_S8_T_ + 17325
7   simutrans                           0x000000010e5e2af5 _ZN10vector_tplI14halt_dist_nodeE9insert_atEjRKS0_ + 4517
8   libdyld.dylib                       0x00007fff736397fd start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
[1]    70171 abort      /Volumes/Horus/Simutrans/simutrans

Looks like an unsigned underflow to me  :laugh:

Offline brunoresende29

  • *
  • Posts: 19
    • Personal Website
  • Languages: EN, PT
Re: 120.4.1 Crash on launch: NSRangeException
« Reply #1 on: January 04, 2020, 02:19:45 PM »
Also, this happens on pak128, pak128.Britain, and pak128.german. On pak128 the game just quits, but on Britain and German I get the following errors:

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5648
  • Languages: EN, NO
Re: 120.4.1 Crash on launch: NSRangeException
« Reply #2 on: January 04, 2020, 07:22:58 PM »
Those last two messages are warnings. Some objects share a name, which means that only one of them will be available in the game. It is either due to incorrectly installed pak sets or add-ons, conflict between add-ons, or a fault in the pak set itself. Some pak sets are known to have such errors, but I don't remember which. These errors are old. Simutrans just started giving warnings about it relatively recently.

As for the crash: Does it crash immediately, during pak set loading, or during game loading (possibly auto loading of the auto saved game)?

Offline brunoresende29

  • *
  • Posts: 19
    • Personal Website
  • Languages: EN, PT
Re: 120.4.1 Crash on launch: NSRangeException
« Reply #3 on: January 04, 2020, 10:27:08 PM »
It happens during early launch, right after I select the pakset. The pakset loading screen then shows and it crashes right after that.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5648
  • Languages: EN, NO
Re: 120.4.1 Crash on launch: NSRangeException
« Reply #4 on: January 05, 2020, 11:01:14 AM »
The exact cause of the error seems obvious: Something is trying to access the last item in an empty array.

What is not clear, is where this is happening. The "readable" parts of entry 4 through 7 are red herrings, although it is puzzling why those symbols are present in the executable, and not others. The use of NSArrayM suggests that it is in some OS X specific part of the code (unless whatever compiler has been used turn regular arrays into that), since that appears, from googling, to be an OS X thing. Someone who can debug on OS X, possibly with a debug build, is likely needed to track this down. Or someone with better psychic debugging skills.

Offline DThunder518

  • *
  • Posts: 17
  • Languages: EN
Re: 120.4.1 Crash on launch: NSRangeException
« Reply #5 on: January 29, 2020, 09:53:54 AM »
This was happening to me too this week on my new Mac. It would happen right after selecting a language. Whenever I would launch the program, it would bring me to the language selection screen. This made me think that maybe it had to do with creating/saving an initial settings file. My solution was to copy ~/Library/Simutrans folder from my old mac to the new one, as well as the Simutrans folder with executable (same version) & paksets into the Applications folder. That worked. The old Mac is on an older version of Mac OS

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5648
  • Languages: EN, NO
Re: 120.4.1 Crash on launch: NSRangeException
« Reply #6 on: January 31, 2020, 11:38:47 AM »
Indeed. Poking around in a disassembly of the executable I found in the Simutrans for Mac zip, there is a call to chdir right before the array is allocated.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5648
  • Languages: EN, NO
Re: 120.4.1 Crash on launch: NSRangeException
« Reply #7 on: January 31, 2020, 11:59:16 AM »
Of course, there are 52 chdir calls in Simutrans.

However, I think I have narrowed it down now. The crash is during MIDI initialization, based on the string constants referenced in that part of the code. dr_midi_stop lacks a check on nowPlaying in both Mac-backends, and can be called in some cases (depending on settings) from midi_set_mute, which is called during startup.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10031
  • Languages: De,EN,JP
Re: 120.4.1 Crash on launch: NSRangeException
« Reply #8 on: January 31, 2020, 12:00:47 PM »
Could you test the nightly for Mac at https://github.com/aburch/simutrans/releases/tag/Nightly

If am not sure the error has been solved in between (since I do not have a Mac), but please give it a try.

EDIT: This only happens, if -nomidi is set on the commandline. r8890 (or the nightly on 1.2.2020 in four hours) should fix this.
« Last Edit: January 31, 2020, 12:26:33 PM by prissi »