Re: gnustep application not running on machines with NVIDIA Optimus chipset

[Eric Wasylishen]

Hi Julian, Fred,

It's odd that such a simple X call would fail. :-/

I have a couple ideas:

- increase the size of the root window from (1,1) to, say, (32,32). (unlikely 
to do anything.. but maybe worth a try?)

- as a sanity check I would add:

printf("current thread: %p\n", (intptr_t)pthread_self());

in a few places to make sure everything is on the same thread.
1. start of main().
2. back/Source/x11/XGServer.m:413 just before XOpenDisplay
3. before the XCreateSimpleWindow call

- lastly, I wonder if it could be 32/64 bit problem, or a problem where the way 
gnustep-back is dynamically loaded is confusing vglrun. IIRC there is a 
gnustep-make option somewhere to compile back as a normal library rather than a 
bundle, so your app is linked to back at build time rather than runtime. May be 
worth a try.

Eric


On 2011-12-14, at 6:05 AM, Julian Mayer wrote:

> hello fred
> 
>> impressive how you come up with all these interesting issues 
> <smile.png>
>> 
>> 
>> 
> 
> i wish i wouldn't be that impressive ;-)
> 
>> I think this time the default screen selection of GNUstep is causing you 
>> trouble. In most cases the default screen should be 0, but for this 
>> optimus technology things seem to be different. You should have a look 
>> at the code in XGServer.m, specifically at _initXContext, here we select 
>> the default screen to use.
>> The first thing to test is to start the application with 
>> --GNU-Debug=dflt (See
>> 
>> 
>> http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_6.html
>> ). 
>> This should report back which screen gets used. Best pipe the error 
>> output stream into a file as we are currently a bit verbose (and also 
>> get quite a few errors report that way that I will have to look into).
>> 
>> This is the line we are interested in:
>> Opened display :0, display 0 screen 0
> 
> thanks for your information. 
> 
> unfortunately i don't have the affected hardware, so i am unable to directly 
> test it.
> 
> fortunately the very same crash appears also on other hardware when just 
> using "VirtualGL" (which the NVIDIA Optimus support project Bumblebee uses) 
> to launch my app.
> 
> the output of "vglrun ./CoreBreach.sh --GNU-Debug=dflt" is 
> 
> Initializing GNUstep x11 backend. 
> Opened display :0.0, display 0 screen 0
> Segmentation Fault
> 
> 
> however, VirtualGL/vglrun doesn't set DISPLAY to something other than 0:0 
> (which i guess bumblebee does) and there also isn't an additional x-server 
> involved. but since the crash is the very same it doesn't seem to be related 
> to the screen number at all.
> 
> the good news to the GNUstep project is that other gnustep apps (helloworld) 
> run fine using vglrun, so they probaby run fine on bumblebee too.
> 
> i've filed a bugreport at bumlebee here - there is already some additional 
> information there:
> https://github.com/Bumblebee-Project/Bumblebee/issues/173
> 
> 
> bye, julian_______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep