Blank, unresponsive window on OS X

[yupferris]

Tried building the latest master (36017f0) on OS X Yosemite (10.10.5), first in debug (as described in the readme) and also in release; same problem with both.

Build process itself was very smooth and fast (well done!!), but when running it (no command line args; $ open ./t2-output/macosx-clang-debug-default/ProDBG.app/) I get a blank, unresponsive window and a pinwheel:

Only things I can do are move the window and force quit :)

[emoon]

Interesting. I will take a look at it over the xmas holidays. Thanks for the report.

[emoon]

Unable to reproduce here :(

What hardware are you running on?

[yupferris]

mid-2014 macbook pro. 2.5ghz i7, 16GB RAM, Intel Iris Pro 1536MB gfx card. I might be able to try some printf debugging and see where it breaks down

[emoon]

Weird :( I have tested on two machines here (Macbook Pro Early 2015 and Mac Pro Late 2013) and it starts correct.. so I'm not sure what's going on. If you run it like:

t2-output/macosx-clang-debug-default/ProDBG.app/Contents/MacOS/prodbg

Do you get any output or so?

[yupferris]

oh woah, opening it like that made it work :P

[yupferris]

full output:

[0:00:00.002] <570f:0> Started thread 'fs_monitor' (570f) ID 400
[0:00:00.018] <570f:0> Started FS event stream for: t2-output/macosx-clang-debug-default
[0:00:00.018] <570f:0> Monitoring file system: t2-output/macosx-clang-debug-default
cerated dock grid 0x0
fastOpenKey 0x4f5
toggleBreakpointKey  0x1290
2015-12-21 11:59:28.780 prodbg[3161:143830] Failed to connect (window) outlet from (ProDBGAppDelegate) to (NSWindow): missing setter or instance variable
/Users/yupferris/dev/projects/ProDBG/api/src/remote/pd_binary_reader.c:120 [DEBUG] no dataSaved layout

[yupferris]

Something's still strange when I open the app the usual way, though.

[emoon]

Weird.. Opening in a usual way works fine for me. It does some 'discovery' where plugins are placed and maybe that goes bad for some reason.

[yupferris]

that might be actually. When I try to open any of the other views than the ones in the default layout they fail with these info messages:

2015-12-21 12:05:43.805 prodbg[3197:147308] Failed to connect (window) outlet from (ProDBGAppDelegate) to (NSWindow): missing setter or instance variable
/Users/yupferris/dev/projects/ProDBG/api/src/remote/pd_binary_reader.c:120 [DEBUG] no data/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0x16
/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0x12
/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0x13
/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0x15
/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0x10
/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0xe
/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0x0
/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0x20e
/Users/yupferris/dev/projects/ProDBG/src/prodbg/main/prodbg.cpp:318 INFO  eventId 0x5

[emoon]

It should print an error if it can't the plugins...

[emoon]

Yeah so when I forced it to fail I get

code/ProDBG/src/prodbg/core/plugin_handler.cpp:251 ERROR Unable to open foo/libworkspace_plugin.dylib

[emoon]

Speculative fix in be5e4da

[yupferris]

No noticeable change after that commit :/

[emoon]

Alright. I will try to drop in a bunch of debug logging tomorrow and see if that helps to figure it out.

[emoon]

I added a "debug-spam" branch. Can you try to get the latest code, switch to that branch and show the output here?

[yupferris]

I just did some super basic instrumentation myself (inserting printf's between all the lines of ProDBG_create and making findDataDirectory only check the current directory for plugins), and when running from another directory than the ProDBG root dir, it reproduced the problem it seems. It appears I got the same error you did when you forced plugin location to fail, but the program keeps running and dumps a ton of stuff to the terminal. My full output can be found here: https://gist.github.com/yupferris/292f38a812d0c7b0aadf

I'll try the debug-spam branch now as well.

[yupferris]

For the record I believe I also had some issues when working on snes-apu-dbg where I couldn't get it to play nice with relative paths.

[emoon]

Ah! I think I know the issue now.. I do a hack right now where I load the plugins for a object_dir path. (which is generate when building) I thought it would have a full path to the directory but it seems to be relative.

[emoon]

I will figure out a way to not loaded it hardcoded.

[yupferris]

That sounds like it'd do it :)

Now ofc I'm having issues getting at the console output when running with open. Is there some standard way to do this? I read somewhere Console.app is supposed to enable this, and I can see a couple messages, but none of the fun spammy stuff we want.

In any case though, the hack you describe is most likely the problem.

[emoon]

Hum... Good question. I always run the executable directly when wanting the TTY output so I'm not sure actually. I guess that is a good reminder that I should just make sure I use my log commands everywhere and dump to a file also :)

[emoon]

Switching Qt and C++ (for now, will be reevaluated when there are some good Rust bindings for Qt) so closing.