Re: gEDA-user: Segfault on startup and garbage drawn outside of pcb board area

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Tue, 2010-06-08 at 01:05 +0200, Krzysztof KoÅciuszkiewicz wrote:
> All,
> 
> I have noticed two bugs with recent git versions of gl-enabled pcb
> (6507083b0401e0).

You're not only using the GL enabled version, but the "poured" region
enabled version. Beware - the behaviour with Polygons on that branch (my
"master" branch is not 100% compatible with stock git HEAD PCB)!

If you're not deliberately using the pour support, you might prefer my
"before_pours" branch, which does not change the semantics for polygon
handling.

(The semantics in the branch you have are that every diced piece of a
polygon is kept, but only those connected to something are retained.
Each diced piece acts separately as far as connectivity is concerned,
and can contribute to different connections.

> 1) Garbage is displayed outside of board area.

I'm not testing the pours branch ("master") as extensively as the
"before_pours" branch, so it is possible there is a bug affecting the
rendering there which I've not corrected. That said, the GL code is
mostly common to both ("master" sits on top of "before_pours").

What graphics card / driver are you using Radeon R300 + Mesa?
This bug is almost certainly going to turn out to be driver dependent.

Since you are using a mesa based driver, try with:

LIBGL_ALWAYS_SOFTWARE=1 pcb ...

and or

LIBGL_ALWAYS_INDIRECT=1 pcb ...

Does this change behaviour?

> 2) pcb sometimes segfaults in glEnable() during startup.

I'd need to see a backtrace of _which_ glEnable() call creates the
problem to be able to start thinking about why that might be..

> I'm using tiling WM and in some cases pcb segfaults during startup.
> I suspect this depends on the order of X events being sent to the
> application. Stack trace is attached. If needed I can do more
> debugging/build with debug libs, but I'm no X expert :)

You need more debug versions of libraries installed to flesh out the
backtrace, but I think I see which glEnable your segfault landed on:

  glEnable (GL_COLOR_LOGIC_OP);

potentially (and perhaps consistent with other symptoms), this code is
being called outside of the correct GL rendering context being set up.
Apparently this doesn't cause problems on my Intel drivers, but is
almost certainly the wrong thing to do...

I'll see if I can hack together together a test patch to stop it doing
that, and perhaps you could report if there is any change in behaviour.

> Should I create items for these in the bug tracker?
> Anybody observed anything similar?

I'm not sure about the tracker - you can do, but if so, please note the
branch and SHA1 as you did above. Let me take a look now to save you the
trouble of filing the bug.. I hate looking through Sourceforge anyway.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user