chromium-users — Mailing list for all users of the Chromuim rendering system

Re: [Chromium-users] GoogleEarth display with Chromium

[Joseph P. <j-...@no...>]

I was able to get that working fairly well, the problem is getting a  
custom view size in Google Earth to match the resolution of a tiled  
chromium application.   Does anyone know of a hack to set  
GoogleEarths view size to something resembling a TWD's resolution?   
640x480 isn't cutting it ;-)

	--Joe

On Sep 21, 2006, at 11:21 AM, Brian Paul wrote:

> Yusuke Tanimura wrote:
>> Hello,
>>
>> I am trying to use Chromium to display GoogleEarth on a 2x3
>> tiled display.  Though I can run the GoogleEarth but the image
>> is a kind of terribly jagged or zig-zag outline.
>>
>> I met the same problem when I tried glplanet with chromium
>> v1.7 but glplanet with chromium 1.8 (Rocks viz) doesn't have
>> the problem anymore.  The GoogleEarth still has the problem
>> even with chromium v.1.9.
>>
>> Each node runs CentOS 4.2 and each screen is 1600x1200.
>> I am not sure if my chromium is configured well.  I attach
>> autodmx.conf which I am using.
>>
>> Does anyone have any idea or have any experiences to run
>> the GoogleEarth with Chromium?  Any comments will be
>> greatly appreciated.
>
> I think I tried this a while back.  I recall having to put an 'array'
> SPU in front of the 'tilesort' SPU.
>
> -Brian
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users

Re: [Chromium-users] Osx

[Brian P. <bri...@tu...>]

Does Cr 1.8 work for you on OS X?

If so, try diff'ing the files under opengl_stub/ and spu_loader/ to 
see what might have changed between 1.8 and 1.9.

-Brian

Re: [Chromium-users] Osx

[Joseph P. <j-...@no...>]

I tried changing the GL includes to use the OSX X11 ones (Not the  
framework), i think the work on this is going to go deeper than a  
simple configuration.

And it seems to be the only definition of CGLSetOption in the code,  
and yes it does seem to be calling it self.  The same goes for the  
CGLChoosePixelFormat.. On nativeOpenGL it calls  
stub.wsInterface.CGLChoosePixelFormat, which also makes me think it's  
recursively calling itself.

	--Joe

On Sep 20, 2006, at 4:57 PM, Joseph Paris wrote:

> Would running under X11 just constitute using the provided X11 shell
> to launch applications? or is there a different setup i need to use?
> I'm new to the Mac end of chromium, so a little green on it's
> configuration.
>
> On that change, i get repeated:
>
> CR Debug(karmacode:15280): CGLChoosePixelFormat: kCGLPFADoubleBuffer
> CR Debug(karmacode:15280): CGLChoosePixelFormat: kCGLPFADepthSize: 12
>
> then the segfault.
>
> Thanks again,
> 	--Joe
>
> On Sep 20, 2006, at 4:44 PM, James Supancic wrote:
>
>> My guess is that the root of the problem has something to do with
>> CGLSetOption, further, I would guess that you may have some mutual
>> recursion going on...
>>
>> The function spewing the message is
>> CGLError CGLSetOption(CGLGlobalOption pname, long param) {
>> //      DEBUG_FUNCTION(CGLSetOption);
>>        crDebug("CGLSetOption( %i )", pname);
>>
>>        stubInit();
>>
>>        return stub.wsInterface.CGLSetOption( pname, param );
>> }
>>
>> code 505 is for the option kCGLGOUseErrorHandler
>>
>> I am not really sure...  you may try changing it to
>> CGLError CGLSetOption(CGLGlobalOption pname, long param) {
>> //      DEBUG_FUNCTION(CGLSetOption);
>>        crDebug("CGLSetOption( %i )", pname);
>>
>>        stubInit();
>>
>>        return noErr;
>> }
>>
>> temporarily for the purpose of debugging. If it fixes the problem we
>> will know a lot more about the problem.
>>
>> Another option might be to use GLX, don't the new Apple hosts support
>> X11? I am not sure if GLX is supported or not...
>>
>> Thank you for your time,
>> James Steven Supancic III
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users

Re: [Chromium-users] GoogleEarth display with Chromium

[Brian P. <bri...@tu...>]

Yusuke Tanimura wrote:
> Hello,
> 
> I am trying to use Chromium to display GoogleEarth on a 2x3
> tiled display.  Though I can run the GoogleEarth but the image
> is a kind of terribly jagged or zig-zag outline.
> 
> I met the same problem when I tried glplanet with chromium
> v1.7 but glplanet with chromium 1.8 (Rocks viz) doesn't have
> the problem anymore.  The GoogleEarth still has the problem
> even with chromium v.1.9.
> 
> Each node runs CentOS 4.2 and each screen is 1600x1200.
> I am not sure if my chromium is configured well.  I attach
> autodmx.conf which I am using.
> 
> Does anyone have any idea or have any experiences to run
> the GoogleEarth with Chromium?  Any comments will be
> greatly appreciated.

I think I tried this a while back.  I recall having to put an 'array' 
SPU in front of the 'tilesort' SPU.

-Brian

Re: [Chromium-users] Crash with multitile-sort

[Brian P. <bri...@tu...>]

Paul Melis wrote:
> Paul Melis wrote:
> 
> 
>>Hello Brian,
>>I'm still experiencing this crash after having recently picked up 
>>looking at it again.
>>Do you have any clue where this could come from and what I should 
>>investigate to get any further?
>> 
>>
> 
> The plot thickens... After compiling the latest CVS version of chromium 
> on a different machine and testing the multitilesort configuration I 
> posted earlier in this thread I don't get a crash. So, it now works for 
> you and for me on some system, but not for me on the system where I need 
> it. This system:
> - is a dual Opteron
> - runs linux 2.6.11, XFree 4.3.0.1, nvidia 87.74 drivers
> - does not have a compiler that outputs 64-bit code, so I set 
> FORCE_32BIT_ABI=1 (and also THREADSAFE=1)
> 
> Any insight would be greatly appreciated,
> Paul
> 
> PS I have one idle machine left. My next attempt will be to move one of 
> the tilesort's to this machine, so that they don't run on the same one

Hmmm, strange.  You might try moving the binaries from the working 
machine to the failing machine to see if it's the software or the 
hardware.

-Brian

Re: [Chromium-users] Osx

[Joseph P. <j-...@no...>]

It definitely seems to be calling itself.  And it seems to be the  
only definition of CGLSetOption in the code.

GLX Is in osx, under the extra X11 utility install umbrella.  I'm  
guessing a possible target using that method would look more like the  
Linux version with the correct dynlib stuff that Osx uses?

	--Joe


On Sep 20, 2006, at 5:51 PM, James Supancic wrote:

> Ok, revert that change and rebuild the server.
>
> After doing so, can you tell me what method is being called by
> stub.wsInterface.CGLSetOption( pname, param ) in CGLSetOption? I
> suspect it may be calling itself? If this is the case it may be a
> simple matter of changing your environment a bit to get things
> working?
>
> I don't have a OSX machine to test things on.
>
> I have no idea how you would configure Chromium to work with GLX on
> OSX. I think you would have to rebuild it for a different target?  I
> think your Chromium is built with the Darwin target, you may have to
> create a new target.
>
> Thank you for your time,
> James Steven Supancic III

Re: [Chromium-users] Crash with multitile-sort

[Paul M. <p.e...@ru...>]

Paul Melis wrote:

>Hello Brian,
>I'm still experiencing this crash after having recently picked up 
>looking at it again.
>Do you have any clue where this could come from and what I should 
>investigate to get any further?
>  
>
The plot thickens... After compiling the latest CVS version of chromium 
on a different machine and testing the multitilesort configuration I 
posted earlier in this thread I don't get a crash. So, it now works for 
you and for me on some system, but not for me on the system where I need 
it. This system:
- is a dual Opteron
- runs linux 2.6.11, XFree 4.3.0.1, nvidia 87.74 drivers
- does not have a compiler that outputs 64-bit code, so I set 
FORCE_32BIT_ABI=1 (and also THREADSAFE=1)

Any insight would be greatly appreciated,
Paul

PS I have one idle machine left. My next attempt will be to move one of 
the tilesort's to this machine, so that they don't run on the same one

-- 
Paul Melis

VR Specialist,
Center for High-Performance Computing & Visualization,
University of Groningen,
The Netherlands

T: +31 50 363 9298
E: p.e...@ru...
W: http://www.rug.nl/rc/hpcv/index

Re: [Chromium-users] Crash with multitile-sort

[Paul M. <p.e...@ru...>]

Brian Paul wrote:

> Paul Melis wrote:
>
>> Brian Paul wrote:
>>
>>> Paul Melis wrote:
>>>
>>>> Brian Paul wrote:
>>>>
>>>>> Paul Melis wrote:
>>>>>
>>>>>> Paul Melis wrote:
>>>>>>
>>>>>>
>>>>>>> Hello,
>>>>>>> While attempting to create a multi-tilesort configuration based 
>>>>>>> on the multitilesort.conf file included with CR1.9 two things 
>>>>>>> happen:
>>>>>>> 1. I get a warning about the state tracker being re-initialized
>>>>>>> 2. One of the crservers crashes (backtrace from the coredump 
>>>>>>> shows it to be in crSPUCopyDispatchTable()).
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Just a bit more info, the crash is happening in 
>>>>>> spu_loader/spucopy.c, crSPUCopyDispatchTable().
>>>>>> In the first for-loop, the assignment temp = 
>>>>>> dst->copy_of->copyList sets temp to 0x1, which is later used as 
>>>>>> temp->copy.
>>>>>>
>>>>>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>>>>>> src=0x817d8c8) at spucopy.c:630
>>>>>> 630                             if (temp->copy == dst)
>>>>>> (gdb) bt
>>>>>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>>>>>> src=0x817d8c8) at spucopy.c:630
>>>>>> #1  0x08087fc5 in crStateDiffAPI (api=0x817d8c8) at state_flush.c:33
>>>>>> #2  0x080515e0 in crServerInit (argc=1, argv=0xffffd494) at 
>>>>>> server_main.c:240
>>>>>> #3  0x08051655 in CRServerMain (argc=1, argv=0xffffd494) at 
>>>>>> server_main.c:254
>>>>>> #4  0x08051012 in main (argc=1, argv=0xffffd494) at main.c:22
>>>>>> (gdb) p temp
>>>>>> $1 = (struct _copy_list_node *) 0x1
>>>>>> (gdb) p dst->copy_of
>>>>>> $2 = (struct _spu_dispatch_table *) 0xffffa520
>>>>>> (gdb)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The demo was crashing for me too, but in a different way. I've 
>>>>> checked in fixes to tilesortspu_get.c and state_bufferobject.c 
>>>>> that fixed things here.  Can you try the current CVS code?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I'm sorry to say it doesn't fix the crash I'm experiencing. The 
>>>> stack trace above is still valid. I've attached a reduced version 
>>>> of my original configuration script. This shows the crash for me 
>>>> when running with e.g. "python multitilesort_crash.conf glxgears", 
>>>> but other apps fail in the same way.
>>>>
>>>> I had some trouble figuring out how exactly to set up the tiling 
>>>> parameters for this setup, so I might be doing something unusual 
>>>> there.
>>>
>>>
>>>
>>>
>>> Hmmm, works for me.
>>>
>>> What's the setting of RELEASE and THREADSAFE in your options.mk file?
>>
>>
>>
>> Both are 0.
>> I (now) guess that threadsafe should be turned on in case multiple 
>> instances of the same SPU are run on the same system?
>
>
> No.  You only need threadsafety if your application makes OpenGL calls 
> from more than one thread.

Hello Brian,
I'm still experiencing this crash after having recently picked up 
looking at it again.
Do you have any clue where this could come from and what I should 
investigate to get any further?

Regards,
Paul



-- 
Paul Melis

VR Specialist,
Center for High-Performance Computing & Visualization,
University of Groningen,
The Netherlands

T: +31 50 363 9298
E: p.e...@ru...
W: http://www.rug.nl/rc/hpcv/index

Re: [Chromium-users] GoogleEarth display with Chromium

[Yusuke T. <yus...@ai...>]

Hi, James,

> "Though I can run the GoogleEarth but the image is a kind of terribly
> jagged or zig-zag outline."
> 
> What image are we talking about? Is the jagged zig-zag outline around
> the entire output window for GoogleEarth, or is it around each
> monitor?

Not entire output.  The view panel which shows the earth is jagged.
The left panel and  navigation panel in the Google Earth window are fine.

> Thank you for your time,
> James Steven Supancic III

--- 
Yusuke Tanimura
Grid Technology Research Center
National Institute of AIST, Japan

Re: [Chromium-users] GoogleEarth display with Chromium

[James S. <arr...@gm...>]

"Though I can run the GoogleEarth but the image is a kind of terribly
jagged or zig-zag outline."

What image are we talking about? Is the jagged zig-zag outline around
the entire output window for GoogleEarth, or is it around each
monitor?

Thank you for your time,
James Steven Supancic III

[Chromium-users] GoogleEarth display with Chromium

[Yusuke T. <yus...@ai...>]

Hello,

I am trying to use Chromium to display GoogleEarth on a 2x3
tiled display.  Though I can run the GoogleEarth but the image
is a kind of terribly jagged or zig-zag outline.

I met the same problem when I tried glplanet with chromium
v1.7 but glplanet with chromium 1.8 (Rocks viz) doesn't have
the problem anymore.  The GoogleEarth still has the problem
even with chromium v.1.9.

Each node runs CentOS 4.2 and each screen is 1600x1200.
I am not sure if my chromium is configured well.  I attach
autodmx.conf which I am using.

Does anyone have any idea or have any experiences to run
the GoogleEarth with Chromium?  Any comments will be
greatly appreciated.

Best regards,

--- 
Yusuke Tanimura
Grid Technology Research Center
National Institute of AIST, Japan

Re: [Chromium-users] Osx

[James S. <arr...@gm...>]

Ok, revert that change and rebuild the server.

After doing so, can you tell me what method is being called by
stub.wsInterface.CGLSetOption( pname, param ) in CGLSetOption? I
suspect it may be calling itself? If this is the case it may be a
simple matter of changing your environment a bit to get things
working?

I don't have a OSX machine to test things on.

I have no idea how you would configure Chromium to work with GLX on
OSX. I think you would have to rebuild it for a different target?  I
think your Chromium is built with the Darwin target, you may have to
create a new target.

Thank you for your time,
James Steven Supancic III

Re: [Chromium-users] Osx

[Joseph P. <j-...@no...>]

Would running under X11 just constitute using the provided X11 shell  
to launch applications? or is there a different setup i need to use?   
I'm new to the Mac end of chromium, so a little green on it's  
configuration.

On that change, i get repeated:

CR Debug(karmacode:15280): CGLChoosePixelFormat: kCGLPFADoubleBuffer
CR Debug(karmacode:15280): CGLChoosePixelFormat: kCGLPFADepthSize: 12

then the segfault.

Thanks again,
	--Joe

On Sep 20, 2006, at 4:44 PM, James Supancic wrote:

> My guess is that the root of the problem has something to do with
> CGLSetOption, further, I would guess that you may have some mutual
> recursion going on...
>
> The function spewing the message is
> CGLError CGLSetOption(CGLGlobalOption pname, long param) {
> //      DEBUG_FUNCTION(CGLSetOption);
>        crDebug("CGLSetOption( %i )", pname);
>
>        stubInit();
>
>        return stub.wsInterface.CGLSetOption( pname, param );
> }
>
> code 505 is for the option kCGLGOUseErrorHandler
>
> I am not really sure...  you may try changing it to
> CGLError CGLSetOption(CGLGlobalOption pname, long param) {
> //      DEBUG_FUNCTION(CGLSetOption);
>        crDebug("CGLSetOption( %i )", pname);
>
>        stubInit();
>
>        return noErr;
> }
>
> temporarily for the purpose of debugging. If it fixes the problem we
> will know a lot more about the problem.
>
> Another option might be to use GLX, don't the new Apple hosts support
> X11? I am not sure if GLX is supported or not...
>
> Thank you for your time,
> James Steven Supancic III

Re: [Chromium-users] Osx

[James S. <arr...@gm...>]

My guess is that the root of the problem has something to do with
CGLSetOption, further, I would guess that you may have some mutual
recursion going on...

The function spewing the message is
CGLError CGLSetOption(CGLGlobalOption pname, long param) {
//      DEBUG_FUNCTION(CGLSetOption);
        crDebug("CGLSetOption( %i )", pname);

        stubInit();

        return stub.wsInterface.CGLSetOption( pname, param );
}

code 505 is for the option kCGLGOUseErrorHandler

I am not really sure...  you may try changing it to
CGLError CGLSetOption(CGLGlobalOption pname, long param) {
//      DEBUG_FUNCTION(CGLSetOption);
        crDebug("CGLSetOption( %i )", pname);

        stubInit();

        return noErr;
}

temporarily for the purpose of debugging. If it fixes the problem we
will know a lot more about the problem.

Another option might be to use GLX, don't the new Apple hosts support
X11? I am not sure if GLX is supported or not...

Thank you for your time,
James Steven Supancic III

Re: [Chromium-users] Osx

[Joseph P. <j-...@no...>]

James,

I was wondering if it was a general problem since it is failing with  
every configuration i've tried with every demo app within chromium.   
 From what i can tell it, is the CrAppFaker that is crashing.   
Everything looks normal up until after the CrAppFaker finds the  
system GL, AGL, CGL paths, then  it prints CGLSetOption(505) a couple  
thousand times and then

CR Debug(karmacode:4789): Dead connection (sock=7, host=karmacode),  
removing from pool
CR Debug(karmacode:4789): Deleting client 0x112a030 (0 msgs left)
CR Debug(karmacode:4789): Last client deleted - empty run queue.
CR Debug(karmacode:4789): Cleaning up SPU render
CR Debug(karmacode:4789): Cleaning up SPU error
CR Error(karmacode:4734): "city" terminated with uncaught signal=11  
(SIGSEGV)


CRserver dumps:
CR Debug(karmacode:4816): Accepted connection from "karmacode".
CR Debug(karmacode:4816): Adding client 0x112a010 to the run queue
CR Debug(karmacode:4816): Added tile: 0, 0 .. 320, 240
CR Info(karmacode:4816): Total output dimensions = (640, 240)
CR Debug(karmacode:4817): Accepted connection from "karmacode".
CR Debug(karmacode:4817): Adding client 0x112a010 to the run queue
CR Debug(karmacode:4817): Added tile: 320, 0 .. 640, 240
CR Info(karmacode:4817): Total output dimensions = (640, 240)
CR Debug(karmacode:4817): Dead connection (sock=7, host=karmacode),  
removing from pool
CR Debug(karmacode:4817): Deleting client 0x112a010 (0 msgs left)
CR Debug(karmacode:4817): Last client deleted - empty run queue.
CR Debug(karmacode:4816): Dead connection (sock=7, host=karmacode),  
removing from pool
CR Debug(karmacode:4817): Cleaning up SPU render
CR Debug(karmacode:4816): Deleting client 0x112a010 (0 msgs left)
CR Debug(karmacode:4816): Last client deleted - empty run queue.
CR Debug(karmacode:4816): Cleaning up SPU render
CR Debug(karmacode:4816): Cleaning up SPU error
CR Debug(karmacode:4817): Cleaning up SPU error


I've tried Mural, crdemo, dist_textures, wall, cr, and simplemural.   
All running off the localhost.  The most simple of configuration 1  
crserver, 1 appfaker has the same problem as the more complex mural  
configs.

Also, city runs fine standalone.

Hope that helps,
	--Joe

On Sep 20, 2006, at 3:42 PM, James Supancic wrote:

> I probably won't be able to help you with the problem, but no one will
> be able to help you with the information you have given.
>
> We need a stack trace from the time of crash. This will tell us were
> (in which function) the crash is occurring in.
>
> Also, please tell about your setup. How many SPUs, which is crashing,
> and in what configuration?
>
> Which node is crashing? An application node, a server node? etc.
>
> Thank you for your time,
> James Steven Supancic III
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users

Re: [Chromium-users] Osx

[James S. <arr...@gm...>]

I probably won't be able to help you with the problem, but no one will
be able to help you with the information you have given.

We need a stack trace from the time of crash. This will tell us were
(in which function) the crash is occurring in.

Also, please tell about your setup. How many SPUs, which is crashing,
and in what configuration?

Which node is crashing? An application node, a server node? etc.

Thank you for your time,
James Steven Supancic III

[Chromium-users] Osx

[Joseph P. <j-...@no...>]

Hey all,

Anyone have any luck getting cr beta 4 running on OSX?  It seems to  
build fine, but every application is segfaulting (even when using the  
most simple of configurations).

Thanks in advance,
	--Joe

[Chromium-users] Custom crServer sync question

[Daniel E. S. <dan...@gm...>]

I have a custom crServer that is embedded into a frame loop. Every frame the
server checks for client data which is drawn along with my custom drawing
updates...  This results in choppy frames because the frames aren't
synchronized that are coming over the wire on a glFlush/SwapBuffers/etc(spu
that no-ops them).  I am trying to find a way to find out when a client(in
our case there will always just be one) is done with the current
frame(buffer swapping for my app is done for me so its out of my control).
I see where I can check to see if the server is in between Begin/End
calls..but not between frames.

Within my draw function I have:

// Bunch of custom drawing above...
   glPushMatrix();
         bool ran_queue = false;
         while(!ran_queue)
         {
            if(cr_server.run_queue != NULL)
            {
           crServerServiceClients();
               ran_queue = true;
            }
         }
   glPopMatrix();


Ideas?

-Dan

Re: [Chromium-users] error while using QT4

[Brian P. <bri...@tu...>]

Christopher Andrews wrote:
> Sorry that took a little bit - one of my colleagues reconfigured our  
> system a little and it took me some time to get back to where I was...
> 
> Anyway, any help you can give me would be much appreciated...
> 
> Here is the stack trace:
> #0  0x00a18410 in __kernel_vsyscall ()
> #1  0x0074aef0 in __nanosleep_nocancel () from /lib/libc.so.6
> #2  0x0074ad3b in sleep () from /lib/libc.so.6
> #3  0x003ccf35 in crSleep (seconds=10) at process.c:29
> #4  0x0033444b in StartMothership () at load.c:467
> #5  0x00334cd5 in stubInit () at load.c:730
> #6  0x0033b979 in glXChooseVisual (dpy=0x97f02d0, screen=0,
>     attribList=0xbf86a408) at glx.c:244
> #7  0x004bba47 in QGLExtensions::init () at qgl_x11.cpp:1348
> #8  0x004bd65e in QGLWidgetPrivate::init (this=0x980ff20,  
> context=0x980f540,
>     shareWidget=0x0) at qgl_x11.cpp:957
> #9  0x004ad4ef in QGLWidget (this=0x980a700, parent=0x0,  shareWidget=0x0,
>     f=@0xbf86a510) at qgl.cpp:2005
> #10 0x0804bb1d in GLWidget (this=0x980a700, parent=0x0) at  glwidget.cpp:32
> #11 0x0804c135 in Window (this=0xbf86a5b4) at window.cpp:31
> #12 0x0804bf1f in main (argc=8, argv=0x33991758) at main.cpp:31

You should continue 'c' at this point.  I'm not sure why gdb stops at 
this point, but it's not what we're interested in.

-Brian

Re: [Chromium-users] error while using QT4

[Brian P. <bri...@tu...>]

Christopher Andrews wrote:
> I have a somewhat odd error problem I'm trying to sort out and I'm  
> hoping someone can help me with. I've been using QT3 and Chromium and  
> didn't really have any problems.
> 
> But, I really would like to be using QT4 and there I have a problem.  
> I have one machine where I run Chromium locally and it works fine,  
> but on our main machine which drives our wall of displays, it just  
> dies. When I fire it up, it connects to all of the remote machines, I  
> get the "crPackReleaseBuffer called with no current buffer" error,  
> the image flashes up on the display and then I have a segfault. The  
> bizarre part is that it just seems to be OpenGL run from within QT4 -  
> everything else still just works.
> 
> I'm still new to using Chromium and I still don't know the best way  
> to even start looking for a solution to a problem like this. I've  
> upgraded to the most recent 1.9 release and I've tried just running  
> it locally with no tiling, just like I do it on my test machine, but  
> it still just crashes.
> 
> If anyone has any experience or suggestions I would be most grateful.  
> It isn't a tremendous problem to regress my code back to QT3, but I'd  
> just as soon avoid it if I can.

Can you compile with RELEASE=0 (options.mk) and send a stack trace 
from the crash?

-Brian

[Chromium-users] error while using QT4

[Christopher A. <cp...@vt...>]

I have a somewhat odd error problem I'm trying to sort out and I'm  
hoping someone can help me with. I've been using QT3 and Chromium and  
didn't really have any problems.

But, I really would like to be using QT4 and there I have a problem.  
I have one machine where I run Chromium locally and it works fine,  
but on our main machine which drives our wall of displays, it just  
dies. When I fire it up, it connects to all of the remote machines, I  
get the "crPackReleaseBuffer called with no current buffer" error,  
the image flashes up on the display and then I have a segfault. The  
bizarre part is that it just seems to be OpenGL run from within QT4 -  
everything else still just works.

I'm still new to using Chromium and I still don't know the best way  
to even start looking for a solution to a problem like this. I've  
upgraded to the most recent 1.9 release and I've tried just running  
it locally with no tiling, just like I do it on my test machine, but  
it still just crashes.

If anyone has any experience or suggestions I would be most grateful.  
It isn't a tremendous problem to regress my code back to QT3, but I'd  
just as soon avoid it if I can.

C. Andrews

Re: [Chromium-users] Crash with multitile-sort

[Brian P. <bri...@tu...>]

Paul Melis wrote:
> Brian Paul wrote:
> 
>> Paul Melis wrote:
>>
>>> Brian Paul wrote:
>>>
>>>> Paul Melis wrote:
>>>>
>>>>> Paul Melis wrote:
>>>>>
>>>>>
>>>>>> Hello,
>>>>>> While attempting to create a multi-tilesort configuration based on 
>>>>>> the multitilesort.conf file included with CR1.9 two things happen:
>>>>>> 1. I get a warning about the state tracker being re-initialized
>>>>>> 2. One of the crservers crashes (backtrace from the coredump shows 
>>>>>> it to be in crSPUCopyDispatchTable()).
>>>>>>
>>>>>>
>>>>>
>>>>> Just a bit more info, the crash is happening in 
>>>>> spu_loader/spucopy.c, crSPUCopyDispatchTable().
>>>>> In the first for-loop, the assignment temp = dst->copy_of->copyList 
>>>>> sets temp to 0x1, which is later used as temp->copy.
>>>>>
>>>>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>>>>> src=0x817d8c8) at spucopy.c:630
>>>>> 630                             if (temp->copy == dst)
>>>>> (gdb) bt
>>>>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>>>>> src=0x817d8c8) at spucopy.c:630
>>>>> #1  0x08087fc5 in crStateDiffAPI (api=0x817d8c8) at state_flush.c:33
>>>>> #2  0x080515e0 in crServerInit (argc=1, argv=0xffffd494) at 
>>>>> server_main.c:240
>>>>> #3  0x08051655 in CRServerMain (argc=1, argv=0xffffd494) at 
>>>>> server_main.c:254
>>>>> #4  0x08051012 in main (argc=1, argv=0xffffd494) at main.c:22
>>>>> (gdb) p temp
>>>>> $1 = (struct _copy_list_node *) 0x1
>>>>> (gdb) p dst->copy_of
>>>>> $2 = (struct _spu_dispatch_table *) 0xffffa520
>>>>> (gdb)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The demo was crashing for me too, but in a different way. I've 
>>>> checked in fixes to tilesortspu_get.c and state_bufferobject.c that 
>>>> fixed things here.  Can you try the current CVS code?
>>>
>>>
>>>
>>>
>>> I'm sorry to say it doesn't fix the crash I'm experiencing. The stack 
>>> trace above is still valid. I've attached a reduced version of my 
>>> original configuration script. This shows the crash for me when 
>>> running with e.g. "python multitilesort_crash.conf glxgears", but 
>>> other apps fail in the same way.
>>>
>>> I had some trouble figuring out how exactly to set up the tiling 
>>> parameters for this setup, so I might be doing something unusual there.
>>
>>
>>
>> Hmmm, works for me.
>>
>> What's the setting of RELEASE and THREADSAFE in your options.mk file?
> 
> 
> Both are 0.
> I (now) guess that threadsafe should be turned on in case multiple 
> instances of the same SPU are run on the same system?

No.  You only need threadsafety if your application makes OpenGL calls 
from more than one thread.

-Brian

Re: [Chromium-users] Crash with multitile-sort

[Paul M. <p.e...@ru...>]

Brian Paul wrote:

> Paul Melis wrote:
>
>> Brian Paul wrote:
>>
>>> Paul Melis wrote:
>>>
>>>> Paul Melis wrote:
>>>>
>>>>
>>>>> Hello,
>>>>> While attempting to create a multi-tilesort configuration based on 
>>>>> the multitilesort.conf file included with CR1.9 two things happen:
>>>>> 1. I get a warning about the state tracker being re-initialized
>>>>> 2. One of the crservers crashes (backtrace from the coredump shows 
>>>>> it to be in crSPUCopyDispatchTable()).
>>>>>
>>>>>
>>>>
>>>> Just a bit more info, the crash is happening in 
>>>> spu_loader/spucopy.c, crSPUCopyDispatchTable().
>>>> In the first for-loop, the assignment temp = dst->copy_of->copyList 
>>>> sets temp to 0x1, which is later used as temp->copy.
>>>>
>>>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>>>> src=0x817d8c8) at spucopy.c:630
>>>> 630                             if (temp->copy == dst)
>>>> (gdb) bt
>>>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>>>> src=0x817d8c8) at spucopy.c:630
>>>> #1  0x08087fc5 in crStateDiffAPI (api=0x817d8c8) at state_flush.c:33
>>>> #2  0x080515e0 in crServerInit (argc=1, argv=0xffffd494) at 
>>>> server_main.c:240
>>>> #3  0x08051655 in CRServerMain (argc=1, argv=0xffffd494) at 
>>>> server_main.c:254
>>>> #4  0x08051012 in main (argc=1, argv=0xffffd494) at main.c:22
>>>> (gdb) p temp
>>>> $1 = (struct _copy_list_node *) 0x1
>>>> (gdb) p dst->copy_of
>>>> $2 = (struct _spu_dispatch_table *) 0xffffa520
>>>> (gdb)
>>>
>>>
>>>
>>>
>>> The demo was crashing for me too, but in a different way. I've 
>>> checked in fixes to tilesortspu_get.c and state_bufferobject.c that 
>>> fixed things here.  Can you try the current CVS code?
>>
>>
>>
>> I'm sorry to say it doesn't fix the crash I'm experiencing. The stack 
>> trace above is still valid. I've attached a reduced version of my 
>> original configuration script. This shows the crash for me when 
>> running with e.g. "python multitilesort_crash.conf glxgears", but 
>> other apps fail in the same way.
>>
>> I had some trouble figuring out how exactly to set up the tiling 
>> parameters for this setup, so I might be doing something unusual there.
>
>
> Hmmm, works for me.
>
> What's the setting of RELEASE and THREADSAFE in your options.mk file?

Both are 0.
I (now) guess that threadsafe should be turned on in case multiple 
instances of the same SPU are run on the same system?

Paul

-- 
Paul Melis

VR Specialist,
Center for High-Performance Computing & Visualization,
University of Groningen,
The Netherlands

T: +31 50 363 9298
E: p.e...@ru...
W: http://www.rug.nl/rc/hpcv/index

Re: [Chromium-users] Crash with multitile-sort

[Brian P. <bri...@tu...>]

Paul Melis wrote:
> Brian Paul wrote:
> 
>> Paul Melis wrote:
>>
>>> Paul Melis wrote:
>>>
>>>
>>>> Hello,
>>>> While attempting to create a multi-tilesort configuration based on 
>>>> the multitilesort.conf file included with CR1.9 two things happen:
>>>> 1. I get a warning about the state tracker being re-initialized
>>>> 2. One of the crservers crashes (backtrace from the coredump shows 
>>>> it to be in crSPUCopyDispatchTable()).
>>>>
>>>>
>>>
>>> Just a bit more info, the crash is happening in spu_loader/spucopy.c, 
>>> crSPUCopyDispatchTable().
>>> In the first for-loop, the assignment temp = dst->copy_of->copyList 
>>> sets temp to 0x1, which is later used as temp->copy.
>>>
>>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>>> src=0x817d8c8) at spucopy.c:630
>>> 630                             if (temp->copy == dst)
>>> (gdb) bt
>>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>>> src=0x817d8c8) at spucopy.c:630
>>> #1  0x08087fc5 in crStateDiffAPI (api=0x817d8c8) at state_flush.c:33
>>> #2  0x080515e0 in crServerInit (argc=1, argv=0xffffd494) at 
>>> server_main.c:240
>>> #3  0x08051655 in CRServerMain (argc=1, argv=0xffffd494) at 
>>> server_main.c:254
>>> #4  0x08051012 in main (argc=1, argv=0xffffd494) at main.c:22
>>> (gdb) p temp
>>> $1 = (struct _copy_list_node *) 0x1
>>> (gdb) p dst->copy_of
>>> $2 = (struct _spu_dispatch_table *) 0xffffa520
>>> (gdb)
>>
>>
>>
>> The demo was crashing for me too, but in a different way. I've checked 
>> in fixes to tilesortspu_get.c and state_bufferobject.c that fixed 
>> things here.  Can you try the current CVS code?
> 
> 
> I'm sorry to say it doesn't fix the crash I'm experiencing. The stack 
> trace above is still valid. I've attached a reduced version of my 
> original configuration script. This shows the crash for me when running 
> with e.g. "python multitilesort_crash.conf glxgears", but other apps 
> fail in the same way.
> 
> I had some trouble figuring out how exactly to set up the tiling 
> parameters for this setup, so I might be doing something unusual there.

Hmmm, works for me.

What's the setting of RELEASE and THREADSAFE in your options.mk file?

-Brian

Re: [Chromium-users] Crash with multitile-sort

[Paul M. <p.e...@ru...>]

Brian Paul wrote:

> Paul Melis wrote:
>
>> Paul Melis wrote:
>>
>>
>>> Hello,
>>> While attempting to create a multi-tilesort configuration based on 
>>> the multitilesort.conf file included with CR1.9 two things happen:
>>> 1. I get a warning about the state tracker being re-initialized
>>> 2. One of the crservers crashes (backtrace from the coredump shows 
>>> it to be in crSPUCopyDispatchTable()).
>>>
>>>
>>
>> Just a bit more info, the crash is happening in spu_loader/spucopy.c, 
>> crSPUCopyDispatchTable().
>> In the first for-loop, the assignment temp = dst->copy_of->copyList 
>> sets temp to 0x1, which is later used as temp->copy.
>>
>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>> src=0x817d8c8) at spucopy.c:630
>> 630                             if (temp->copy == dst)
>> (gdb) bt
>> #0  0x5557f040 in crSPUCopyDispatchTable (dst=0x80d62c0, 
>> src=0x817d8c8) at spucopy.c:630
>> #1  0x08087fc5 in crStateDiffAPI (api=0x817d8c8) at state_flush.c:33
>> #2  0x080515e0 in crServerInit (argc=1, argv=0xffffd494) at 
>> server_main.c:240
>> #3  0x08051655 in CRServerMain (argc=1, argv=0xffffd494) at 
>> server_main.c:254
>> #4  0x08051012 in main (argc=1, argv=0xffffd494) at main.c:22
>> (gdb) p temp
>> $1 = (struct _copy_list_node *) 0x1
>> (gdb) p dst->copy_of
>> $2 = (struct _spu_dispatch_table *) 0xffffa520
>> (gdb)
>
>
> The demo was crashing for me too, but in a different way. I've checked 
> in fixes to tilesortspu_get.c and state_bufferobject.c that fixed 
> things here.  Can you try the current CVS code?

I'm sorry to say it doesn't fix the crash I'm experiencing. The stack 
trace above is still valid. I've attached a reduced version of my 
original configuration script. This shows the crash for me when running 
with e.g. "python multitilesort_crash.conf glxgears", but other apps 
fail in the same way.

I had some trouble figuring out how exactly to set up the tiling 
parameters for this setup, so I might be doing something unusual there.

Paul


-- 
Paul Melis

VR Specialist,
Center for High-Performance Computing & Visualization,
University of Groningen,
The Netherlands

T: +31 50 363 9298
E: p.e...@ru...
W: http://www.rug.nl/rc/hpcv/index