[fossil-users] Broken repo leads to bad free and SIGSEGV when editing checkin comments

[Jonathan Hankins]

Hello,

TL;DR: One-line patch seems to fix it:

--- db.c.orig   2015-09-14 20:14:25.324662150 -0500
+++ db.c2015-09-14 20:17:01.742666003 -0500
@@ -2015,7 +2015,7 @@
 if( zDefault==0 && pSetting && pSetting->def[0] ){
   z = fossil_strdup(pSetting->def);
 }else{
-  z = zDefault;
+  z = mprintf("%s", zDefault);
 }
   }
   return z;



Not sure how my original repo got into this state, but I was able to
reproduce my issue.

Symptom was, I could not edit the existing comments on several checkins on
my trunk.  As soon as I clicked the "edit" link on the checkin page, I got
an empty browser page that says "ERR_EMPTY_RESPONSE" (Chrome).  Other
operations seem to be OK, and I was able to create a new branch and keep
working there.

Started digging, and the child process is getting SIGSEGV at info.c:2703

[This is fossil version 1.33 [f6c13632bb] 2015-09-12 19:18:28 UTC]

[ci_edit_page()]

2703   if( zBranchName ) fossil_free(zBranchName);

Here's what's happening: for some reason, several of the checkins in trunk
are missing the record in the tagxref table with tagid = 8 (TAG_BRANCH),
 This results in an empty response in from db_text() at info.c:2620

[ci_edit_page()]

2620   zBranchName = db_text(0, "SELECT value FROM tagxref, tag"
2621  " WHERE tagxref.rid=%d AND tagtype>0 AND tagxref.tagid=tag.tagid"
2622  " AND tagxref.tagid=%d", rid, TAG_BRANCH);

Then at info.c:2662:

2662   if( !zBranchName ){
2663 zBranchName = db_get("main-branch", "trunk"); /* 2nd arg "trunk"
is value for zDefault, see below */
2664   }

In my config table (fresh repo) there is no value for "main-branch" even
though the settings GUI has "trunk" in the text box (presumably as a
default, when there is no main-branch setting in the db, but I haven't
looked.)  So, at db.c:2018, it falls back to using "zDefault":

[db_get()]

2014   if( z==0 ){
2015 if( zDefault==0 && pSetting && pSetting->def[0] ){
2016   z = fossil_strdup(pSetting->def);
2017 }else{
2018   z = zDefault;
2019 }
2020   }
2021   return z;
2022 }

Resulting in an attempted free() on a the const string "trunk" passed as
zDefault in the call to db_get.

This crashes the child of the "server" process with SIGSEGV.

To duplicate, create a new repo and make some checkins.  Run sqlite on the
db, and:

delete from tagxref where tagid = 8 order by rid desc limit 1;

This will break the most recent checkin -- try clicking the "edit" link to
verify.

-Jonathan Hankins
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ++ignore option

[Jonathan Hankins]

First of all, is this the intended behavior?

Secondly, is this common enough to warrant complicating the processing of
the existing --ignore option?

If yes and yes, then syntax you propose seems unnatural to me.  How about:

--ignore +CSG (a la NET-SNMP mibdirs handling, maybe allow for -CSG too)

Currently, you get a syntax error if you try to specify --ignore multiple
times.  I suppose it might be nice to be able to say something like:

--ignore +foo,qux --ignore -bar,baz

or equivalently, if specifying multiple --ignore options is undesirable:

--ignore +foo,qux,-bar,baz

(also equivalently)

--ignore +foo,+qux,-bar,-baz



-Jonathan Hankins

On Mon, Apr 27, 2015 at 1:54 PM, Ron W ronw.m...@gmail.com wrote:

 The existing --ignore option overrides any ignores in the project's
 settings. Sometimes, it would be very useful to have a ++ignore option to
 specify additional ignores.


 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users