[OSX] Editor crashes when playing a line with 'P'

[bohning]

Instant crash, presumably also on other operating systems.

[basisbit]

most likely portaudio or some other 3rd party library changed their api so that setting the audio volume fails

[RattleSN4K3]

Is this still in issue? It isn't in latest versions.

It should have been fixed with c83c37911bda7096150f4456b62772745f1429b8. Due to the files missing, the following line crashes (accessing null pointer) as SoundLib.Click is nil: SoundLib.Click.Volume := SelectsS[VolumeClickSlideId].SelectedOption / 100;

The stream, Click, isn't created as the relevant file wasn't found, resulting into the following line return nil - for every Sound stream variable: Click := AudioPlayback.OpenSound(SoundPath.Append('rimshot022b.mp3'));

[basisbit]

can't test because I don't get USDX to run on OS X any more. Dependency hell on OS X is so annoying that I personally don't care about supporting OS X any more. Wasted a couple of hours on it again today.

[RattleSN4K3]

It happened on Windows as well due to the access pointer crash (missing audio file). I'm sure it'll work if you get a OSX version to build.

The problem doesn't rely on SoundLib.Click.Volume := 0; but SoundLib.Click = nil resulting to true.

[basisbit]

mischi will do a build based on libraries from the fink repository next week for the release, so that should be ok for a beta then.

[RattleSN4K3]

For me a beta can wait. I prefer less builds than having a release cycle like firefox :wink:. If you name it 1.3.0b (equivalent to 1.0.1a), what would be the next proper release named/versioned?

[basisbit]

last release is about 6 years old ;-)

[RattleSN4K3]

Nearly 5... but convinced.

But what's the next version? From 1.3.0b to 1.3.1? 1.4.0 already? 1.3.0 / 1.3.0 Final?

PS: Gitter.

[bohning]

Basisbit, with the fork of rhaamo (and with brew instead of fink), I was able to compile it on OSX like a charm.

[basisbit]

The fork from rhaamo was integrated into our master. Bohning, could you try compiling please?

[bohning]

Yes, will probably be able to compile it tonight.

[bohning]

Hey guys, I just updated my sources, compiled like a charm - however, it doesn't run.

This is what I get when I start the executable in the console from within the app:

Markuss-MBP:MacOS markus$ ./ultrastardx dyld: lazy symbol binding failed: Symbol not found: _SDL_Init Referenced from: /Users/markus/Projects/USDX/UltraStarDeluxe.app/Contents/MacOS/./ultrastardx Expected in: dynamic lookup

dyld: Symbol not found: _SDL_Init Referenced from: /Users/markus/Projects/USDX/UltraStarDeluxe.app/Contents/MacOS/./ultrastardx Expected in: dynamic lookup

Trace/BPT trap: 5 Markuss-MBP:MacOS markus$

Any ideas or hints? Thanks in advance!

[basisbit]

huh, same problem that I got. Most likely caused by the commit which upgraded SDL2 headers to 2.0.4 because that reverted a bunch of changes form rhaamo

[bohning]

I guess so. Using rhaamo's branch and the following the README, it used to compile without issues.

[bohning]

Maybe this thread is of any help?

http://forums.libsdl.org/viewtopic.php?t=5997&sid=73840727929628eced1704a39bdc7fba

[RattleSN4K3]

The SDL2 headers were modified? The specific commit was a copy of the downloaded source files (through github not git).

The update to 2.0.4 headers doesn't change that much: https://github.com/UltraStar-Deluxe/USDX/commit/19a86ebf6c593c9ef43e705725c041b0c488f7ba?w=1

The relevant change would be the definition of the lib name which now includes a custom name. The actual lib wasn't exchanged.

What does the configure log say? Is it really related to that specific commit or any previous one?

[bohning]

config.log.txt

[basisbit]

I'd guess the issue is https://github.com/UltraStar-Deluxe/USDX/commit/19a86ebf6c593c9ef43e705725c041b0c488f7ba?w=1#diff-7646d13e080f9a1cdc10fad1625eca29L160 . Will check this in about an hour.

[RattleSN4K3]

I thought the same since the config.log.txt doesn't state that linking is a problem. The question remains, is it really a matter of the lib or the configuration. I couldn't find where "libSDL2" ("libSDL2.dylib") is used.

configure:4905: $PKG_CONFIG --exists --print-errors "sdl2" configure:4908: $? = 0 configure:4928: result: yes (-L/usr/local/lib)

Some other projects state, that it could be the ase the path is not in the library path env. Check with echo $LIBRARY_PATH and see of the path is there.

Another case could be where the compiler does not have sufficient permission to access the file.

[bohning]

$LIBRARY_PATH seems to be empty:

Markuss-MBP:USDX markus$ echo $LIBRARY_PATH

Markuss-MBP:USDX markus$

I am compiling with "sudo make macosx-standalone-app", so it should have all required access rights, shouldn't it?

[basisbit]

please check out and try again

[bohning]

Now it compiles and runs, the screen turns black and then it crashes:

Markuss-MBP:MacOS markus$ ./ultrastardx 2016-07-20 00:08:24.360 ultrastardx[48938:2147893] 00:08:24.360 WARNING: 140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h. An unhandled exception occurred at $00000001000B04C3: EAccessViolation: Access violation $00000001000B04C3 $00000001000679E5

[basisbit]

same here :-\ But closer to working.

[basisbit]

I'll check commit for commit to find when it broke

[AlexanderS]

You know about git bisect (aka. the helper for finding the commit that broke stuff)?

[basisbit]

yes, am already doing that. slowly narrowing it down. looks like my last commit fixed what the SDL2.0.4 update broke but apparently the introduction of dglOpenGL broke getting the OpenGL context

[basisbit]

it crashes in src/lib/dglOpenGL/dglOpenGL.pas line 19615 "AnsiBuffer := glGetString(GL_VERSION); ". currently no idea why or how to fix it

[RattleSN4K3]

I read a bit, but nothing I could pin point externally. But...

Can we close this issue and re-create a new one related to the OSX build. The main problem here was the crash when playing a line in the editor. It was a problem in Windows as well (not only OSX) and with the mentioned commit, it got solved. Thinking, it also got fixed for OSX (if anyone can properly build a version for it).

[bohning]

Yay, I can confirm this problem is fixed with the latest version on OSX as well. "P" plays the current lyrics line as expected. Great job!

[RattleSN4K3]

K thx. Closing this one.