octave-maintainers
[Top][All Lists]
Advanced

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

Re: Problem in parse-tree/lex.ll when make-checking


From: Rik
Subject: Re: Problem in parse-tree/lex.ll when make-checking
Date: Sat, 07 Mar 2015 09:25:00 -0800

On 03/07/2015 08:01 AM, address@hidden wrote:
> Subject:
> Re: Problem in parse-tree/lex.ll when make-checking
> From:
> Pantxo <address@hidden>
> Date:
> 03/07/2015 07:43 AM
> To:
> address@hidden
> List-Post:
> <mailto:address@hidden>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden>
> In-Reply-To:
> <address@hidden>
> Message-ID:
> <address@hidden>
> Content-Type:
> text/plain; charset=UTF-8
> Message:
> 3
>
> Julien Bect-2 wrote
>> > Le 05/03/2015 08:35, Julien Bect a écrit :
>>> >> [...]
>>> >>
>>> >> Ok, I think I have found it. The test is attached.
>> >
>> > Oooops, sorry, I forgot the attachment. But you can see the test in the
>> > mail anyway.
>> >
>>> >> # ./run-octave --no-gui
>>> >>
>>> >> [...]
>>> >>
>>> >> parse-tree/lex.ll :2697 : void octave_base_lexer::handle_number():
>>> >> l'assertion « nread == 1 » a échoué.
>>> >> panic: Abandon -- stopping myself...
>>> >> Abandon (core dumped)
>> >
>> > One more detail : I first ran into this problem while running "make
>> > check" as root.
>> >
>> > The isolated failure reported in my previous email was also obtained
>> > while running as root.
>> >
>> > If I run the same test as an ordinary user, I don't see the failure any
>> > more.
>> >
>> > HTH...
> A bug report on this issue has been filed [1]. As the reporter also had
> non-english locale, I tried myself and found that the segfault disappeared
> if I first set LC_NUMERIC to "en_US".
> @Julien: Do your root and normal user accounts have different locales ?
>
> Pantxo
>
> [1] https://savannah.gnu.org/bugs/index.php?44469


Pantxo,

I think we may have been through this cycle once before.  I remember experiments with what Matlab does and it apparently sets LC_NUMERIC to 'C' regardless of the current locale.  We copied this behavior in octave.cc.

-- Code --
octave_initialize_interpreter (int argc, char **argv, int embedded)
{
  // Matlab uses "C" locale for LC_NUMERIC class regardless of local setting
  setlocale (LC_NUMERIC, "C");
  setlocale (LC_TIME, "C");
-- End Code --

As a first check, could you try setting LC_NUMERIC to "C" instead of "en_US" and see if the tests still pass?

If that passes, then I think the problem is why LC_NUMERIC is not being set.  Maybe this is related to the fact that octave is now just a dispatcher to octave-cli and octave-gui.  Perhaps because we do an exec, rather than a fork, some aspects of the environment are not transferred to the subsidiary process.  Just guessing, I could be completely wrong here.

--Rik





reply via email to

[Prev in Thread] Current Thread [Next in Thread]