[Crash-utility] __error() mucks with pc->tmpfile
Dave Anderson
anderson at redhat.com
Mon Dec 17 16:43:19 UTC 2012
----- Original Message -----
> I spent today trying to figure out why some parsing was going awry.
> The problem stems from trying to emit a warning message while
> reprocessing the pc->tmpfile data. viz.:
>
>
> open_tmpfile();
> hq_open();
> count = do_list(&ld);
> hq_close();
> rewind(pc->tmpfile);
> while (fgets(buf, sizeof(buf), pc->tmpfile) != 0) {
> if (something_wrong(buf)) {
> error(WARNING, "something wrong");
> continue;
> }
> ... etc.
>
> After the error() invocation, the data have been scribbled on because
> of this code:
> if ((fp != stdout) && (fp != pc->stdpipe)) {
> fprintf(fp, "%s%s%s %s", new_line ? "\n" : "",
> type == WARNING ? "WARNING" :
> type == NOTE ? "NOTE" :
> type == CONT ? spacebuf : pc->curcmd,
> type == CONT ? " " : ":",
> buf);
> fflush(fp);
> }
>
> "fp" being a global variable that is set to pc->tmpfile.
> I suppose you can say, "works as expected", but it surely isn't as
> I would expect. How about a nice "standard_error" wrapper that
> hides and restores that "fp" global variable thingy while invoking
> __error()? I can do it myself, but I really do not think it
> advisable for crash client code to fiddle with what seems to me
> to be internal state.
>
> Thanks! - Bruce
Right -- I would never expect error() to be called while inside
an open_tmpfile() operation. Normally the behind-the-scenes data
is parsed, and if anything is to be displayed while open_tmpfile()
is still in play, it would be fprint()'ed using pc->saved_fp.
So I'm not sure what the best way to handle your client code
that does just that. I haven't tested it, but as I understand
it, you would see the error message printed both to stdout (from
the else part of the if-else code above the code segment you show
above), and then again in your overwritten/parsed code. If that's
true, then I guess there should just be a prevention of the
secondary output above if pc->tmpfile is in play.
Dave
More information about the Crash-utility
mailing list