Intermittent errors launching yab apps, either bound or compiled.

[bbjimmy]

I am working on .hpkg files for yab. Testing, I have found that both applications bound to the interpreter, and applications compiled with BuildFactory have trouble launching.

I am using yab1.7.02, ​http://fatelk.com/yab/yab1.7.02.hpkg and the buildfactory and example Calc program, part of ​http://haikuware.com/directory/view-details/development/editors/unofficial-yab-17-fixed-paste-error-of-textedit .

The program launches ok about 60% of the time, the rest of the time it complains and offers to save a report.

Calc.bin-939-debug-08-02-2014-22-39-46.report.txt is for the bound version

Calc-2902-debug-08-02-2014-21-34-30.report.txt is for the compiled version.

note: Launching the script without binding or compiling it into an executable stand-alone progrem works without the error.

[bbjimmy]

debug report for bound app

[bbjimmy]

debug report for compiled app

[bbjimmy]

Interestingly, if I add some "pause .1" commands to the script then compile, the issue goes away. This slows down the window drawing enough to notice, makes it look like a Windows xp program starting up rather than a snappy HAIKU program, but it doesn't seem to error on launch.

hmmm

Looks like something is in a race condition.

[bonefish]

Indeed, this sounds like a race condition. If this didn't happen before with the same code, the new scheduler might have changed the timings.

According to the crash reports in both cases YabList::AddView() is called on a NULL pointer. Nothing in the stack trace suggests that this is a Haiku bug.

[bbjimmy]

This does not appear to be a yab issue.

I have done some more testing. All I have to do to avoid the issue is add a .01 secind pause as the first command in the file. I believe this is allowing haiku to catch-up after loading the program into memory. The YabList::AddView() is called from the yab open window command to open the main window. the pause many commands before the openwindow command insuring that the pointer ( that is created within the open window command ) is not null seems to suggest that the new schedular's changed timings has dammaged valid code.

[bonefish]

A different scheduling behavior cannot break valid code. It can, however, expose problems in already broken code. In principle the scheduler changes could have broken locking primitives like semaphores, but that seems rather unlikely, since I would expect a much greater fallout.

Again, so far there's nothing indicating that the issue is not in yab. Since it seems to readily reproducible, it should be fairly easy to track down.

[bbjimmy]

Interestingly enough, hrev46953 no longer exhibits these errors. yab now works as expected, and yab apps compiled on hrev46953, BeOS R5, and Haiku r1a4.1 now all work as expected. This was a yab problem?

[umccullough]

If the yab code expects things to run in a certain order (scheduler-related issue), then the code should be set to do so properly. It sounds as if there is some race condition in code that needs proper locking.

Saying "it's not a yab issue" because you added a delay, or it worked on a previous version is simply ignorance of proper multithreading code.

In short - if it's magically "fixed" now after further scheduler tweaking, it's probably going to break again in the future.