[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: confusing message in Debian gcc "bug is not reproducible, so it is likely a hardware or OS problem"



On Mon, Sep 24, 2012 at 03:14:42PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 24, 2012 at 02:10:50PM +0200, Basile Starynkevitch wrote:
> > Ok, to say it in other words:
> > 
> >    experimentally, a plugin which calls fatal_error (and this is definitely an
> >    acceptable behavior for plugins) makes Debian GCC output the original message,
> >    which is very confusing since the error is really called by a plugin.
> >    I have no idea if a plugin problem is considered or not as a non reproducible bug.
> >    But certainly, a fatal_error from a plugin's pass should not make GCC gives a
> >    message which suggest hardware issues, while it is simply due to some plugin.
> > 
> > It would be very nice if the error message contained the "plugin" word (at least
> > when some plugin is used).
> 
> You should get that message only if the problem is not reproduceable, i.e.
> the exit code, stdout or stderr of the compiler is different between the
> several invocations the driver retries.  So, the plugin would need to emit
> different errors or exit code in each case.  Is your plugin that broken?

Could you explain a bit more what are the conditions to get that message? 
What source file (of what Debian patch of GCC) is producing that?

Is the gcc driver attempting to re-run again the cc1 with the plugin? I
'm not sure I want that (the MELT plugin is forking some processes itself, 
using pseudo random numbers eventually seeded thru /dev/random or time(2), 
hashing some pointer addresses, etc.. so the details of its behavior are 
certainly non deterministic). How could I avoid the message?

Wouldn't it be simpler to add the plugin word in the message, 
just in case (this will confuse a lot less potential users)? 
Again, a GCC plugin could legitimately have non-deterministic 
or non-reproducible behavior (just think of a plugin interacting with a 
web service or a remote database, or using random numbers)

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***


Reply to: