| 1 |
On Sun, 2011-02-06 at 12:48 +0100, Fabian Groffen wrote: |
| 2 |
> On 31-01-2011 10:50:59 +0000, Alan Hourihane wrote: |
| 3 |
> > On FreeMiNT there is an issue with the logfile that I've never traced |
| 4 |
> > and always had to disable it, with a bit of hackery. But revisiting has |
| 5 |
> > shown me in SpawnProcess.py there is a function called _can_log which |
| 6 |
> > always returns TRUE. |
| 7 |
> > |
| 8 |
> > What's the best way to make this return FALSE on FreeMiNT, until I can |
| 9 |
> > trace the root cause ? |
| 10 |
> |
| 11 |
> Do you have a backtrace or something? Maybe we can easily fix it, |
| 12 |
> instead of working around it. The code seems to use some gzip |
| 13 |
> "encoder", perhaps its missing on your end (though unlikely if you ask |
| 14 |
> me) |
| 15 |
|
| 16 |
I don't get a backtrace, just this..... |
| 17 |
|
| 18 |
* The ebuild phase 'compile' has exited unexpectedly. This type of |
| 19 |
* behavior is known to be triggered by things such as failed variable |
| 20 |
* assignments (bug #190128) or bad substitution errors (bug #200313). |
| 21 |
* Normally, before exiting, bash should have displayed an error message |
| 22 |
* above. If bash did not produce an error message above, it's possible |
| 23 |
* that the ebuild has called `exit` when it should have called `die` |
| 24 |
* instead. This behavior may also be triggered by a corrupt bash binary |
| 25 |
or |
| 26 |
* a hardware problem such as memory or cpu malfunction. If the problem |
| 27 |
is |
| 28 |
* not reproducible or it appears to occur randomly, then it is likely |
| 29 |
to |
| 30 |
* be triggered by a hardware problem. If you suspect a hardware problem |
| 31 |
* then you should try some basic hardware diagnostics such as memtest. |
| 32 |
* Please do not report this as a bug unless it is consistently |
| 33 |
* reproducible and you are sure that your bash binary and hardware are |
| 34 |
* functioning properly. |
| 35 |
|
| 36 |
Alan. |
Archives