----- 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility