bugGNU Octave - Bugs: bug #44029, Decimal number input parsing...


bug #44029: Decimal number input parsing depends on locale

Submitted by:  None
Submitted on:  Sat 17 Jan 2015 04:30:55 PM UTC  
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Mirko Hessel-von Molo Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  3.8.2
Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Wed 18 Mar 2015 07:58:43 AM UTC, comment #13: 

My current build, that includes Rik's patch, works ok when launched from a terminal with French locale. As the problem appeared somewhat inconsistently this may not be a definite conclusion.
I am closing this bug report. I'll try to check regularly that the problem hasn't reappeared and reopen this report if necessary.

Pantxo Diribarne <pantxo>
Project Member
Wed 18 Mar 2015 02:23:01 AM UTC, comment #12: 

Pantxo, can you test whether this is now fixed for you with the change made for bug #44469?


Mike Miller <mtmiller>
Project Administrator
Fri 06 Feb 2015 02:07:59 PM UTC, comment #11: 

@Mirko: Thanks for clarifying that it does this reliably every time for you, while for Pantxo it comes and goes. It still never happens for me, but my system is set up for en_US system-wide and I'm trying different locale settings in my shell environment only.

@Pantxo: Yes, imread or imwrite, and for Java something simple like `javaObject("java.lang.String")` is enough to load the JVM.

Debugging where exactly the setlocale function gets called, with what arguments, and what library it's using while the GUI is starting could be quite difficult due to the way the process forks when running in GUI mode.

Mike Miller <mtmiller>
Project Administrator
Fri 06 Feb 2015 08:52:03 AM UTC, comment #10: 

@Mike: I (originator of the bug report) could produce the bug immediately after startup, ie without having called anything.

Are there any sensible tests I could make? Referring to Pantxos previous comment (Is it using the same setlocale implementation?) could it be that the OS sometimes dynamically links one, sometimes another library implementation? In this case occurence of the bug would depend on the state of the OS, not only of the Octave process itself.  What kind of "state property" would that be? The contents of /etc/ld.so.conf ? How can that be inspected?

Best, Mirko

Fri 06 Feb 2015 08:12:05 AM UTC, comment #9: 

@Mike: what java related function should I try? The java dialogs are available in cli only, where the bug does not occur. I tried "imread" several times and it does not seem to trigger the bug on my current build.

Pantxo Diribarne <pantxo>
Project Member
Fri 06 Feb 2015 03:01:11 AM UTC, comment #8: 

@Pantxo: Does this bug correlate with using either image or Java functions in Octave? I see two places in Octave where the locale setting is saved and restored, and they have to do with initializing the GraphicsMagick library and the JVM. If you call an image function or a Java function, does this bug happen any more reliably?

Mike Miller <mtmiller>
Project Administrator
Mon 02 Feb 2015 05:00:25 PM UTC, comment #7: 

As the output of "setlocale (LC_ALL, NULL)" is known to depend on the implementation [1], I wonder: are we always picking the same "setlocale" implementation? Do we use gnulib for this or system one (or both ...)?

[1] http://www.cplusplus.com/reference/clocale/setlocale/

Pantxo Diribarne <pantxo>
Project Member
Mon 02 Feb 2015 04:20:38 PM UTC, comment #6: 

This is an erratic bug, it comes and go for the same build. The attached test function retrieves the locale. When the bug doesn't appear or in cli mode the output is:


which shows that LC_NUMERIC has the expected value. When the bug appears (sometimes, in the GUI only), the output is simply

ans =fr_FR.UTF-8;

No variable name, simply the main locale.
To build the function and reproduce:

mkoctfile get_locale.cc
get_locale ()

(file #32974)

Pantxo Diribarne <pantxo>
Project Member
Mon 02 Feb 2015 10:27:43 AM UTC, comment #5: 

mirkoh@mlt171:~$ printf "%.6f\n" 1
mirkoh@mlt171:~$ LC_NUMERIC=C printf "%.6f\n" 1

Mon 02 Feb 2015 04:35:20 AM UTC, comment #4: 

The only way I can get this to happen on my system is by commenting out the following lines in libinterp/octave.cc:

  //setlocale (LC_NUMERIC, "C");
  //setlocale (LC_TIME, "C");

If I then set my locale to de_DE.utf8 or fr_FR.utf8, I get the same incorrect results reported here. If I leave those lines compiled in, then the locale in my environment doesn't affect how numbers are read or written.

Is it possible that the "C" locale doesn't exist or is configured differently on some systems?

For the reporter or other people affected by this bug, what do the following display in a bash shell?

$ printf "%.6f\n" 1
$ LC_NUMERIC=C printf "%.6f\n" 1

Mike Miller <mtmiller>
Project Administrator
Thu 22 Jan 2015 03:30:02 PM UTC, comment #3: 


I think this is the same bug I had already reported (bug #37928) and I can confirm it still happens on my system (linux mint 17.1) with french locale, on self built dev 4.1.

The previous bug had been closed because I thought it had disappeared, but I have faced this crash randomly since then and didn't take time to reopen the bug report.

Pantxo Diribarne <pantxo>
Project Member
Sat 17 Jan 2015 08:27:50 PM UTC, comment #2: 


Sat 17 Jan 2015 08:09:29 PM UTC, comment #1: 

Thank you for the report.
I have tested  the versions 3.8.2 and 3.9.0+  with German locales on Ubuntu 14.04. and the '.' was interpreted as expected.
What are the values of the other LC_* environment variables on your system?

Torsten Lilge <ttl>
Project Member
Sat 17 Jan 2015 04:30:55 PM UTC, original submission:  

I am using a freshly compiled Version 3.8.2 with GUI on Ubuntu 14.04 with German localization (i. e. de_DE.UTF-8 chosen in locale configuration). I experience obviously incorrect interpretation of decimal number input. Both interactively or from a script file, a statement like

>> a = 1.3

results in the answer

a = 1

i. e. returning only the integer part of the input. Saying instead

>> a = 1+3/10

using only integers gives the correct answer

a = 1.3000

I suspected that it might be an issue with the point character not being interpreted as a decimal point due to the German locale and tried starting Octave by issueing

LANG=en_US.UTF-8 GDM_LANG=en_US LANGUAGE=en_US /usr/local/libexec/octave/3.8.2/exec/i686-pc-linux-gnu/octave-gui --force-gui

from the command line. In the GUI now starting,
decimal input appears to be interpreted correctly.

This behaviour is not found in the CLI version.

I use the above workaround for the time being. It might also be used in the install script, however I am not able to provide a properly formulated patch for this.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #32974:  get_locale.cc added by pantxo (1022B - text/x-c++src)


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-05-14 mtmiller Dependencies- => bugs #45101 is dependent
    2015-03-18 pantxo StatusWorks For Me => Fixed
        Open/ClosedOpen => Closed
    2015-03-01 pantxo Dependencies- => bugs #44400 is dependent
    2015-02-02 pantxo Attached File- => Added get_locale.cc, #32974
    2015-02-02 mtmiller StatusNone => Works For Me

    Back to the top

    Powered by Savane 3.5