Example code:
int main() { array x=({ ({128,0,"TiMidity","TiMidity port 0"}), ({128,1,"TiMidity","TiMidity port 1"}), }); write("Ports available:\n%{%3d:%-3d %-32.32s %s\n%}",x); }
In the latest Pikes, this may segfault or produce horribly wrong data; a --with-debug build emits a fatal "sprintf: fs->fsp incorrect after recursive sprintf.". Bisecting a non-debug build pointed to 7fdf94 as the crash culprit, but I couldn't replicate that bisection on a debug build for some reason (the build didn't finish for several commits).
The problem seems to occur when %{ %} results in a reallocation of the format_info_stack at the top of low_pike_sprintf (sprintf.c:1026). There's a ptrdiff_t that doesn't seem to be used anywhere, and which could be connected. I'm not sure why 7fdf94 should bring in the problem, though, as it looks like a direct - almost mechanical - translation.
ChrisA
Thanks for the report. The translation was somewhat mechanical, but I somehow messed that up. Fixed in 8.0.
arne
On Sun, 1 Jun 2014, Chris Angelico wrote:
Example code:
int main() { array x=({ ({128,0,"TiMidity","TiMidity port 0"}), ({128,1,"TiMidity","TiMidity port 1"}), }); write("Ports available:\n%{%3d:%-3d %-32.32s %s\n%}",x); }
In the latest Pikes, this may segfault or produce horribly wrong data; a --with-debug build emits a fatal "sprintf: fs->fsp incorrect after recursive sprintf.". Bisecting a non-debug build pointed to 7fdf94 as the crash culprit, but I couldn't replicate that bisection on a debug build for some reason (the build didn't finish for several commits).
The problem seems to occur when %{ %} results in a reallocation of the format_info_stack at the top of low_pike_sprintf (sprintf.c:1026). There's a ptrdiff_t that doesn't seem to be used anywhere, and which could be connected. I'm not sure why 7fdf94 should bring in the problem, though, as it looks like a direct - almost mechanical - translation.
ChrisA
On Sun, Jun 1, 2014 at 9:42 PM, Arne Goedeke el@laramies.com wrote:
Thanks for the report. The translation was somewhat mechanical, but I somehow messed that up. Fixed in 8.0.
That does cure the problem, but now it's not possible for the "fs->fsp incorrect" trap to happen at all. Was there an actual potential problem that that was supposed to be catching?
ChrisA
That debug check is a left over from before 061713bf4d5ca4673144690f164a48856c289b57, when the format stack had a static size. Its purpose was to detect bugs in the format stack handling. It should be removed now.
arne
On Sun, 1 Jun 2014, Chris Angelico wrote:
On Sun, Jun 1, 2014 at 9:42 PM, Arne Goedeke el@laramies.com wrote:
Thanks for the report. The translation was somewhat mechanical, but I somehow messed that up. Fixed in 8.0.
That does cure the problem, but now it's not possible for the "fs->fsp incorrect" trap to happen at all. Was there an actual potential problem that that was supposed to be catching?
ChrisA
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Chris Angelico