Re: new upstream gEDA bug fix release
On Fri, Feb 06, 2009 at 02:28:51PM +0100, Luk Claes wrote:
> Hamish Moffatt wrote:
> > Could the RMs please comment on this proposed change? I realise we are
> > in deep freeze now but this discussion started well before that. Some of
> > the bugs fixed are serious (though logged upstream rather than in our
> > BTS).
>
> The problem is that the previous version has not migrated to testing yet
> and it looks like it will only be just in time for the release.
Oh? It looks ready to go in now if only hppa would upload geda-gschem,
and geda-gnetlist, and probably others. They've been built at least once
each.
> Upstream seems to always update all these components even if there are
> no real changes, but just for consistency? If so, I think it would be
> best if after the release you move them all to the same source package
> to prevent these wastes of time on the buildds because they depend on
> each other. What do you think?
I agree, and upstream is planning to do this themselves for the next
major release. It'll making building the package so much easier, as well
as testing migration etc.
> > Is there anything I can do to make the review easier?
>
> What are these serious bugs?
>From geda-gschem's ChangeLog, there's a few crashes fixed.
commit 22d9457c68d756675facc5acfebebca96299a766
Author: Peter TB Brett <peter@peter-b.co.uk>
Date: Tue Dec 30 23:49:17 2008 +0000
Validate calls to scm_c_eval_string(). [2105219]
Because the reporter's version of Guile is broken, a lovely garbage
collector segfault occurs if a null string is passed to
scm_c_eval_string().
For now, replace most calls to scm_c_eval_string() with user-provided
arguments by g_scm_c_eval_string_protected(), and modify the latter to
behave well with a NULL argument. This has the added advantage of
providing backtraces in more places.
Cherry-picked from: 2a4fdb13021d0153e788fe3b2fc005f273dcdf4b
16102ef095c959b5c1febb9b9259dda23c739258
commit 469f81a602ea8c5228f1553f6ee785499f24905e
Author: Peter Clifton <pcjc2@cam.ac.uk>
Date: Sun Dec 21 23:38:40 2008 +0000
gschem: Remove stretched object from stretch list if we delete it
When a stretched object becomes zero length when rubberbanding, we
delete it. We must also remember to delete it from the stretch list,
otherwise it will be referenced later, and could cause a crash.
NB: This isn't the whole story.. the before / after connectivity
lists can still reference the deleted object and cause a crash.
(based on commit fe8640898cb843b72e1c3cc01ee52c33db736ccf)
Edited since the STRETCH list is not a GList in the 1.4.x series, and
other cleanup work on this file is not present.
commit 66140fd3956e8d4523c8a7ecc63e519144b9c4c6
Author: Peter Clifton <pcjc2@cam.ac.uk>
Date: Sun Dec 21 23:38:40 2008 +0000
gschem: Check for self-connecting COMPLEX before deleting. Fix #1912859
Remove any references to objects inside the COMPLEX being deleted
when we build the list of objects to redraw on screen following the
COMPLEX's deletion.
This fixes a crash observed when deleting symbols with co-incident pins.
(Based on commit 3d8b3efb5a4ce8672133658ccdbe5c57d341f0fc)
Edited because OBJECT->complex_parent is only set on the HEAD node of
a complex's prim_objs. Rather than traversing the whole object list to
find the HEAD node each time, instead check each connected object against
each of the deleted object's prim_objs.
and geda-gnetlist:
commit 7b17b576aac3f59d880d5d28234833b3a9d82e26
Author: Peter Clifton <pcjc2@cam.ac.uk>
Date: Sun Dec 21 22:19:13 2008 +0000
gnetlist: Fixup systemc backend
Don't escape < and > characters in strings, as guile doesn't like this.
Apply similar fixes as those made to the VHDL and verilog backends after
some changes in gnetlist to accomodate slotting in spice-sdb. Since the
netlist backend is loaded before gnetlist has traversed the schematic, it
must not execute any code which queries gnetlist on load. All such work
is to be done only when gnetlist invokes the "systemc" method.
Move (define c_p #f) to outside (systemc:components ...)'s (lambda ...)
function, since guile doesn't appreciate us mixing declarations and
expressions. This variable is tested and (set! c_p #t) later on, which
doesn't feel very scheme like. The fix works for now though.
Check to see if the regexp matched netname, checking for "name<type>" has
hit a match before trying to get a piece of that match. If the regexp
returns #f, instead just treat the identifier as a "name" and use that.
This allows net names which don't conform to the regexp to at least give
some vaguely sensible output, without crashing the backend.
Comment some debugging prints to stdout, giving a cleaner looking run.
(cherry picked from commit bfd49ad477a49235c3e5ee1eda54e5009f6e347a
and commit d13aadcbac4af912e0555b3696b59fc904c6cd9f)
commit b9daae67b8af2c6a8d3bba3a921823c888b65614
Author: Dan McMahill <dan@mcmahill.net>
Date: Tue Dec 9 09:15:25 2008 +0000
Avoid insecure temp file usage.
Fixes the security vulnerability noted in http://secunia.com/advisories/32806/
The issue is insecure temp file usage. The fix is to create a private directory
and keep temp files in there.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
Reply to: