> Hi Joe,
>
> I have fixed the problem. The box_value_struct() VM function was
> called with the wrong address, and so the data in the stack frame was
> not boxed properly. "cocoa" test passes now, and so does your test
> case, however the UI still doesn't work.
>
> Slava

Thanks a lot, Slava. At this point I'm kinda stumped as to what's  
causing the UI to fail. When the system tries to activate the window  
by calling -[NSWindow makeKeyAndOrderFront:], it segfaults in the  
middle of -[NSView _drawRect:clip:] when that method gets called on  
the FactorView. The guts of _drawRect:clip: appear to be attempting to  
call an invalid address stored somewhere in the bowels of AppKit.  
Something obvious must be getting missed in the application, window,  
or view's initialization.

When the view code dies, the UI winds up in a loop because the ui- 
error-hook tries to open a new debugger window, which dies in a  
similar fashion and triggers the ui-error-hook again, causing it to  
loop trying to spawn windows until it runs out of GL contexts to  
allocate, leading to the "invalid code module"/"invalid context" noise  
getting spammed to the console. You can get a better trace of what's  
happening if you replace the ui-error-hook with a simple dump to the  
console, like:

USING: ui ui.gadgets.worlds ;
[ error. :s :r :c flush ] ui-error-hook set-global

-Joe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to