Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#10520 closed bug (invalid)

Intermittent errors launching yab apps, either bound or compiled.

Reported by: bbjimmy Owned by: nobody
Priority: normal Milestone: R1
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (2)

Calc.bin-939-debug-08-02-2014-22-39-46.report.txt (10.8 KB) - added by bbjimmy 5 years ago.
debug report for bound app
Calc-2902-debug-08-02-2014-21-34-30.report.txt (11.1 KB) - added by bbjimmy 5 years ago.
debug report for compiled app

Download all attachments as: .zip

Change History (8)

Changed 5 years ago by bbjimmy

debug report for bound app

Changed 5 years ago by bbjimmy

debug report for compiled app

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by bonefish

Resolution: invalid
Status: newclosed

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.

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by 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?

comment:6 Changed 5 years ago by 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.

Note: See TracTickets for help on using tickets.