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.
|
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?
http://hg.savannah.gnu.org/hgweb/octave/rev/e75a0fe1eee2
|
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.
|
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.
|
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?
|
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/
|
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
No variable name, simply the main locale.
To build the function and reproduce:
(file #32974)
|
Mon 02 Feb 2015 10:27:43 AM UTC, comment #5:
mirkoh@mlt171:~$ printf "%.6f\n" 1
1,000000
mirkoh@mlt171:~$ LC_NUMERIC=C printf "%.6f\n" 1
1.000000
|
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:
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?
|
Thu 22 Jan 2015 03:30:02 PM UTC, comment #3:
Hi,
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.
|
Sat 17 Jan 2015 08:27:50 PM UTC, comment #2:
LANG=de_DE.UTF-8
LANGUAGE=de_DE
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
|
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?
|
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
results in the answer
i. e. returning only the integer part of the input. Saying instead
using only integers gives the correct answer
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
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.
|