On Sat, 2008-01-12 at 21:37 +0000, a r wrote:
> Hmm.. I'll try to nail it down. I guess, it happens in the object
> iteration loop but I couldn't recreate the problem. If you could
> please help me with this crash that would be great.
Run gschem under valgrind:
valgrind gschem
When all the warnings from XLib and guile have gone past, hit enter a
bunch of times to create space a nice identifiable point in the scroll
back.
Place some nets..
Lets make the first:
-----------
|
| __ (CLICK)
|/
.
|
|
|______.(CLICK).
At the second click, you get it blow up as libgeda joins the two
co-linear net segments:
==7689== Invalid read of size 4
==7689== at 0x8071881: o_net_add_busrippers (o_net.c:768)
==7689== by 0x807304D: o_net_end (o_net.c:513)
==7689== by 0x808716B: x_event_button_pressed (x_event.c:305)
==7689== by 0x47041DD: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84)
==7689== by 0x43BD771: g_closure_invoke (gclosure.c:490)
==7689== by 0x43CE322: signal_emit_unlocked_R (gsignal.c:2440)
==7689== by 0x43CF60E: g_signal_emit_valist (gsignal.c:2209)
==7689== by 0x43CFA08: g_signal_emit (gsignal.c:2243)
==7689== by 0x4822497: gtk_widget_event_internal (gtkwidget.c:4675)
==7689== by 0x46FD36E: gtk_propagate_event (gtkmain.c:2317)
==7689== by 0x46FE586: gtk_main_do_event (gtkmain.c:1537)
==7689== by 0x422FB99: gdk_event_dispatch (gdkevents-x11.c:2351)
==7689== Address 0x7C33818 is 0 bytes inside a block of size 208 free'd
==7689== at 0x402237F: free (vg_replace_malloc.c:233)
==7689== by 0x442C960: g_free (gmem.c:187)
==7689== by 0x407643B: s_delete_object (s_basic.c:440)
==7689== by 0x4076513: s_delete (s_basic.c:472)
==7689== by 0x406FC0F: o_net_consolidate_segments (o_net_basic.c:558)
==7689== by 0x8072FDA: o_net_end (o_net.c:492)
==7689== by 0x808716B: x_event_button_pressed (x_event.c:305)
==7689== by 0x47041DD: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84)
==7689== by 0x43BD771: g_closure_invoke (gclosure.c:490)
==7689== by 0x43CE322: signal_emit_unlocked_R (gsignal.c:2440)
==7689== by 0x43CF60E: g_signal_emit_valist (gsignal.c:2209)
==7689== by 0x43CFA08: g_signal_emit (gsignal.c:2243)
(And lots more to follow before death)
The bug here appears to be that o_net_add_busruppers() is called with a
list generated before the consolidation happened (see the second
backtrace of how the memory was free'd).
Looks like it is caled in o_net_end() too. After the call to
o_net_consolidate_segments(), all bets are off, you have to be REALLY
careful with any object lists and pointers you had previously.
This code is not ideal really, as for maximum flexibility we want the
possibility of libgeda modifying such things without gschem having to
take such pains to tread carefully.
Once the drawing model is more polished (I'm working on a different
approach with the cairo based rendering), gschem shouldn't won't need to
explicitly call so many redraw functions with lists of objects - making
the problem much much simpler. (It is _mostly_ redrawing that these
pointers are kept for.)
> > Another possible logic to consider (which I've seen in some pacakge,
> but
> > can't remember which..) is to have a net drawing like this:
> >
> > 2. X-Axis becomes fixed when you:
> > |
> > \|/
> > -------- <--- 1. (Y-Axis already fixed from previous segment start)
> > |
> > | /|\
> > |/--- 3. Click here, but |
> > ------------------------------ 4. this last horiz. segment
> > | can still move up and
> down.
> > \|/
> >
> > Ending on a pin or double clicking (perhaps) would end drawing.
> This is mostly equivalent to the logic I want to implement (point 2).
I know where I saw this logic now.. it was KiCad (credit where it is
due).
> I can imagine more elaborate scheme involving a full-blown routing
> algorithm. But unless it is done perfectly it is going to cause more
> problems than a simpler but more predictable solution.
I've seen this work nicely.. and I've seen it go very wrong (Xilinx
tools where adding a net to a neighbouring component went around the
entire page)
--
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!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
