Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OSX] Crash with selecting music #3648

Closed
DorpsGek opened this issue Feb 26, 2010 · 9 comments
Closed

[OSX] Crash with selecting music #3648

DorpsGek opened this issue Feb 26, 2010 · 9 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

planetmaker opened the ticket and wrote:

trunk r19268

How to reproduce:
Unpack the attached music set in your personal gm dir (~/.openttd/gm or here ~/Documents/OpenTTD/gm)
Start the game, select OpenMSX-r4 and then start or load a map
Select the jukebox and then programme
Programme such that "Little Blue Box Car" is not the only one. When that song is about to be played, OpenTTD crashes (see attached files). With a sequential order and skip tracks I managed to mess up such that the crash message window showed, but OpenTTD hung there, to be "kill -9"ed only.

Attachments

Reported version: trunk
Operating system: Mac OS X


This issue was imported from FlySpray: https://bugs.openttd.org/task/3648
@DorpsGek
Copy link
Member Author

Rubidium wrote:

I can't reproduce it on Linux, Yexo can't reproduce it on Windows. The crash log is completely, excluding the crash logger, somewhere in Apple's code. This means it's very likely that the bug is in Apple's code.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648#comment7630

@DorpsGek
Copy link
Member Author

DorpsGek commented Mar 8, 2010

Chakotay wrote:

Manged to reproduce it on Mac OS X 10.6.2 with rev 19374.
I just let OpenTTD run with the music on in the background.
After 5 minutes or so, it crashed repeatedly somewhere deep in CoreAudio.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648#comment7682

@DorpsGek
Copy link
Member Author

planetmaker wrote:

Indeed. With a bit of patience this happens also out of the blue without any user interaction (r19318)


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648#comment7770

@DorpsGek
Copy link
Member Author

Chakotay wrote:

rev. 19615

Tested it again today with Mac OS X 10.6.3 and the latest development tools (Xcode 3.2.2) from Apple.
Doesn't seem to happen anymore. Let all the songs play through about 2 times.

Might have been fixed in update to 10.6.3?
Does it still occur with anyone using that version?


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648#comment7853

@DorpsGek
Copy link
Member Author

DorpsGek commented May 2, 2010

matheweis wrote:

I just tested with Mac OS X 10.6.3 and Xcode 3.2.2, and was able to replicate the crash, so it does not appear to have been fixed. I tested both 1.0.1 and r19750.

Of note, I was able to replicate it much more easily by quickly cycling between songs. If I waited until the songs changed by themselves it only happened once.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648#comment7968

@DorpsGek
Copy link
Member Author

DorpsGek commented May 2, 2010

matheweis wrote:

I spent some time extensively looking into this bug this afternoon, and came to the following two conclusions:

  1. The MIDI file LittleBlueBoxCar.mid is almost certainly corrupt.

The audio sounded significantly different in three different MIDI players that I tested it with. Also, I own a copy of Logic Express, and when attempting to import the file to look at the notes, I was informed of a "Data conflict while reading Track 2".

  1. Corrupted MIDI file aside, there IS a bug in the Mac OS CoreAudio.

I wrote up a 40 line test application that loaded and played the midi file, so we could eliminate all the other factors. If the program was run with DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib, it crashed immediately and consistently on a memory overflow deep in Core Audio... but ONLY on the one midi file. All others did not crash the program. I've attached the program if you want to look it over.

I went ahead and filed a bug report with Apple (Problem ID 7932088), but I have no idea how long that process will take.

Only two things come to mind as far as solutions - neither are very elegant, but I will just throw them out there:
a. Call it good and move on, since the midi file was almost certainly corrupted
b. Implement some alternative pre-parsing of midi files to ensure validity of the files before feeding them to the OS.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648#comment7969

@DorpsGek
Copy link
Member Author

planetmaker wrote:

So... as windows driver crashes are not a bug. Is this then not a bug either? The song doesn't exist anyway anymore within OpenMSX...


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648#comment8508

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Requested by user


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648

@DorpsGek
Copy link
Member Author

matheweis wrote:

I realized this bug has been closed, but for reference, Apple has responded to my bug report, and (I have verified) has fixed the CoreAudio bug as of Mac OS X 10.6.5


This comment was imported from FlySpray: https://bugs.openttd.org/task/3648#comment9106

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant