Sorry, that last one is wrong. Instead, change: http://fossil-scm.org/index.html/artifact?ln=1385&name=cc8d06a2d208ad00
To: while(0); tmp = 0 (with no trailing semicolon) ----- stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Jun 7, 2017 05:21, "Stephan Beal" <sgb...@googlemail.com> wrote: > Aaaand: add 1 line between these two: > > http://fossil-scm.org/index.html/artifact?ln=1380-1381&; > name=cc8d06a2d208ad00 > > Add: > > tmp = 0; \ > > To avoid a separate (potential) corner case bug. > > > ----- stephan > Sent from a mobile device, possibly from bed. Please excuse brevity, > typos, and top-posting. > > On Jun 7, 2017 05:07, "Stephan Beal" <sgb...@googlemail.com> wrote: > >> The error is triggered here: >> >> http://fossil-scm.org/index.html/artifact?ln=1518-1525&name= >> cc8d06a2d208ad00 >> >> Because of: >> ... Hmmm... i THINK (not certain) it's because >> json_respone_command_path() is, via, json_create_response() returning null >> because of missing data in g.json. It interprets that as an alloc error, >> but it's really a corner case. It could be fixed by adjusting: >> >> http://fossil-scm.org/index.html/artifact?ln=1413-1415&name= >> cc8d06a2d208ad00 >> >> To simply wrap that SET() callin if(tmp). >> >> i think. >> >> Wow, amazing what one can accomplish with fossil on a tablet from bed. >> >> >> >> >> ----- stephan >> Sent from a mobile device, possibly from bed. Please excuse brevity, >> typos, and top-posting. >> >> >> On Jun 7, 2017 04:44, "Stephan Beal" <sgb...@googlemail.com> wrote: >> >> Here we go: >> http://fossil-scm.org/index.html/info/2accaaeeadd34cb6 >> >> >> >> ----- stephan >> Sent from a mobile device, possibly from bed. Please excuse brevity, >> typos, and top-posting. >> >> On Jun 7, 2017 04:41, "Stephan Beal" <sgb...@googlemail.com> wrote: >> >>> Afaik, all errors except allocation failures do return the error in json >>> form (i had to jump through some hoops to get that working way back then, >>> due to fossil's fail-fast-via-exit() approach to error handling). The >>> mis-triggered alloc report here is, as you say, likely a side effect of >>> the null fields, and should be easy to fix. >>> >>> Note that you don't need http to feed data to the json layer. There is a >>> cli option (i think it's -json-input, but i am in bed so can't verify that >>> right now) which tells it to read the POST data from a file. >>> >>> >>> ----- stephan >>> Sent from a mobile device, possibly from bed. Please excuse brevity, >>> typos, and top-posting. >>> >>> On Jun 7, 2017 04:05, "Warren Young" <war...@etr-usa.com> wrote: >>> >>>> On Jun 6, 2017, at 5:58 PM, Stephan Beal <sgb...@googlemail.com> wrote: >>>> > >>>> > If you leave quotes off of the property names, it's not json >>>> >>>> Yes, but that’s only one of the three problems here. The other two are: >>>> >>>> 1. It should diagnose the error correctly. (The error has nothing to >>>> do with memory allocation.) >>>> >>>> 2. It should return the error message via JSON to the client, not print >>>> it on the console. The JSON API is most likely to be used in cases where >>>> the called Fossil instance is running in the background, with stdio >>>> detached. >>>> >>>> > Why that shows up as a response allocation error, i can't say off >>>> hand. >>>> >>>> From what debugging I did, it’s because the parsing failure caused most >>>> of the fields of g.json to be unset, which causes multiple levels of NULL >>>> to be returned, which the scream-and-die code misinterprets as given. >>>> _______________________________________________ >>>> fossil-users mailing list >>>> fossil-users@lists.fossil-scm.org >>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>>> >>> >>
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
