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

On Mon, Sep 24, 2012 at 1:27 PM, Basile Starynkevitch
<basile@starynkevitch.net>
> I suggest to replace it with
>
> The bug is not reproducible, so it could be a plugin, hardware or OS problem

slight update :
The bug is not reproducible, so it could be an external problem :
A plugin, hardware or OS problem


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAF0qKV0DA0oVY13GVovOrS598CdZHfpeZCFZn8zZitjMr7Bc4 A@mail.gmail.com">http://lists.debian.org/CAF0qKV0DA0oVY13GVovOrS598CdZHfpeZCFZn8zZitjMr7Bc4 A@mail.gmail.com

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

On 24.09.2012 13:27, Basile Starynkevitch wrote:
> Hello All,
>
> See http://gcc.gnu.org/ml/gcc/2012-09/msg00232.html for details about my suggestion.
>
> The message
> The bug is not reproducible, so it is likely a hardware or OS problem
> is apparently Debian specific http://gcc.gnu.org/ml/gcc/2012-09/msg00234.html

this is a patch applied to Debian, Ubuntu, and afaik to Fedora (orginating from
Jakub).

> But it is very confusing, since plugin failures also trigger it.
>
> I suggest to replace it with
>
> The bug is not reproducible, so it could be a plugin, hardware or OS problem

Why should it be a plugin problem if it's not reproducible?

Matthias


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 506048C9.9000608@debian.org">http://lists.debian.org/506048C9.9000608@debian.org

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

On Mon, Sep 24, 2012 at 01:49:29PM +0200, Matthias Klose wrote:
> On 24.09.2012 13:27, Basile Starynkevitch wrote:
> > Hello All,
> >
> > See http://gcc.gnu.org/ml/gcc/2012-09/msg00232.html for details about my suggestion.
> >
> > The message
> > The bug is not reproducible, so it is likely a hardware or OS problem
> > is apparently Debian specific http://gcc.gnu.org/ml/gcc/2012-09/msg00234.html
>
> this is a patch applied to Debian, Ubuntu, and afaik to Fedora (orginating from
> Jakub).
>
> > But it is very confusing, since plugin failures also trigger it.
> >
> > I suggest to replace it with
> >
> > The bug is not reproducible, so it could be a plugin, hardware or OS problem
>
> Why should it be a plugin problem if it's not reproducible?


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).

BTW, if you want to reproduce the problem (you could make some stub plugin calling fatal_error, or)
you could fetch (today, since I'll update the gcc-melt.org site soon)

http://gcc-melt.org/melt-0.9.7-rc1-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz

Then build it according to instructions on http://gcc-melt.org/
Then install it with
(make install DESTDIR=/tmp/meltinstdir ; sudo cp -vrp /tmp/meltinstdir/usr/. /usr/.)

Then make an empty file with

touch empty.c

at last compile it with

gcc -g -O -Wall -fplugin=melt -fplugin-arg-melt-mode=eval -fplugin-arg-melt-arg=class_source -c empty.c


You'll get a lot of error messages, the last one being a
cc1: fatal error: MELT plugin module compilation failed (512) in ....

then at last

compilation terminated.
The bug is not reproducible, so it is likely a hardware or OS problem.

And I (and other MELT users) really find this last sentence very confusing;
it is not the hardware's or the system's fault, it is just my melt plugin which is buggy.

I prefer MELT users to report such bugs to me (the MELT plugin guy), not to
their hardware vendor or Debian supplier!

Regards

PS. MELT is a high level domain specific language to extend GCC, and it works by generating C code,
compiling it (by forking some make), and dlopen-ing it (all this inside the same cc1 process)

--
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} ***


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120924121050.GA8543@hector.lesours

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

On 24.09.2012 14:10, Basile Starynkevitch wrote:
> On Mon, Sep 24, 2012 at 01:49:29PM +0200, Matthias Klose wrote:
>> On 24.09.2012 13:27, Basile Starynkevitch wrote:
>>> Hello All,
>>>
>>> See http://gcc.gnu.org/ml/gcc/2012-09/msg00232.html for details about my suggestion.
>>>
>>> The message
>>> The bug is not reproducible, so it is likely a hardware or OS problem
>>> is apparently Debian specific http://gcc.gnu.org/ml/gcc/2012-09/msg00234.html
>>
>> this is a patch applied to Debian, Ubuntu, and afaik to Fedora (orginating from
>> Jakub).
>>
>>> But it is very confusing, since plugin failures also trigger it.
>>>
>>> I suggest to replace it with
>>>
>>> The bug is not reproducible, so it could be a plugin, hardware or OS problem
>>
>> Why should it be a plugin problem if it's not reproducible?
>
>
> 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).

Basile, maybe you could extend the patch that it only adds the hint for the
plugin if some -plugin options are passed?


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50605919.6050806@debian.org">http://lists.debian.org/50605919.6050806@debian.org

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

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?

Jakub


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120924131442.GC1787@tucnak.redhat.com">http://lists.debian.org/20120924131442.GC1787@tucnak.redhat.com

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} ***


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120924142428.GA9022@hector.lesours

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

On 24.09.2012 16:24, Basile Starynkevitch wrote:
> 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?

debian/patches/gcc-ice-hack.diff


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50606FCA.80000@debian.org">http://lists.debian.org/50606FCA.80000@debian.org

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

On Mon, Sep 24, 2012 at 04:35:54PM +0200, Matthias Klose wrote:
> On 24.09.2012 16:24, Basile Starynkevitch wrote:
> > 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?
>
> debian/patches/gcc-ice-hack.diff

I really believe that a GCC plugin may have non-deterministic (or simply,
difficult to reproduce) behavior, and still be valid (imagine a plugin producing a
unique serial number, or a plugin querying some remote database or web service).
So I believe that at least for plugins, GCC should not automagically restart,
and when it does restart, it should say so.

And MELT's behavior is non deterministic, e.g. because it is itself forking a make
(since MELT plugin is generating C code, compiling it by make, then dlopen-ing it, all from
the same 'cc1 -fplugin=melt' process), because it is using randomly generated hash codes
(random being by default seeded thru time(2) or /dev/random), etc. I don't expect MELT failures
to be exactly the same.

I am attaching a slightly improved version of gcc-ice-hack.diff

Could you suggest me a way of detecting if a vendor GCC has this patch.
I was thinking of something like

if [ strings $(which gcc) | grep -q 'bug is not reproducible, so it is likely a hardware or OS' ]; then
### do something
fi

Regards.
--
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} ***