Activity for Takashi Yano
-
Takashi Yano posted a comment on ticket #30
Cygwin replaces these chars with unicode chars of 0xf000 | ch. Therefore, cygwin can treat these chars as a part of filename. Of course, they cannot be displayed properly outside cygwin.
-
I confirmed that the issue was fixed in the head of master (5.5) and branch-5-4-stable. Thanks!
-
Oh, v5.4.5 was not applied the following commit yet. commit 780f8bd414e67c6a226efa7952e134d732feb283 Author: Takashi Yano <tyan0@users.sourceforge.net> Date: Tue Feb 15 22:44:15 2022 +0100 windows console: buffered pipe input Use read() instead of fgetc() to improve read speed. Avoid mixed access to pipe by our pipe reading thread and C file functions to prevent race condition. Bug #2491 (cherry picked from commit c128262f2f57aa53174d3bb7b672aff6ee3a9b79) I see.
-
Thanks! I also can confirm that the issue is already fixed in branch-5-4-stable (5.4.6 alpha). So, we can expect the issue will most likely not occur in the next release.
-
(Windows v5.4.5) Plotting binary data from stdin does not work.
-
I noticed that the previous patch breaks the UCRT compatibility. Fixed version is attached.
-
I noticed that the previous patch breaks the UCRT compatibility. Fixed version attached.
-
I noticed that the previous patch breaks the UCRT compatibility. Fixed version attached.
-
I noticed that the previous patch breaks the UCRT compatibility. Fixed version attached.
-
Fix a problem caused when console output is buffered. Change the condition to call the code to fix the problem. Fix behaviour for UNICODE mode. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Change the condition to execute the code to fix the problem. Fix behaviour for UNICODE mode. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Change the condition to execute the code to fix the problem. Fix behaviour for UNICODE mode. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Change the condition to execute the code to fix the problem. Fix behaviour for UNICODE mode. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Fix behaviour for UNICODE mode. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Fix behaviour for UNICODE mode. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Some bug fixes and improvements. Add missing error handling.
-
Fix a problem caused when console output is buffered. Some bug fixes and improvements.
-
Fix a problem caused when console output is buffered. Some bug fixes.
-
Fix a problem caused when console output is buffered. Some bug fixes.
-
Fix a problem caused when console output is buffered. Some bug fixes.
-
Fix a problem caused when console output is buffered. Some bug fixes.
-
Fix a problem caused when console output is buffered. Some bug fixes.
-
Fix a problem caused when console output is buffered. Some bug fixes.
-
Fix a problem caused when console output is buffered. Some bug fixes.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Fix a problem caused when console output is buffered.
-
Patch is revised in the git format-patch format.
-
Fixed a few bugs.
-
The previous patches have undesired side effects. The new patch introduces another very different strategy rather than using _setmode(). With this patch, multibyte char is outputted in one action using the buffer even if user code output it by separate calls.
-
Revised once more.
-
Revised again on one point.
-
Revised just a bit.
-
Revised.
-
The patch revised a bit again.
-
The patch revised furthermore.
-
The patch revised a bit.
-
The patch revised further.
-
Revised again.
-
The patch revised.
-
I have built a patch for this issue as attached. This is PoC patch and the file name and its location may not be appropriate.
-
I have built a patch for this issue as attached.
-
I found a workaround for this issue. Adding if (_isatty(_fileno(stdout))) _setmode(_fileno(stdout), _O_BINARY); after setlocale() solves the issue. Now I am trying to imply this into mingw.
-
This seems to be a problem of msvcrt.dll. The following code also fails in the same way. #include <windows.h> #include <stdio.h> #include <locale.h> int main() { char buf[] = {0x83, 0xbf, '\n', 0}; /* "α\n" in CP932 */ int (*__putchar)(int); char *(*__setlocale)(int, char *); HMODULE h = LoadLibrary("msvcrt.dll"); __setlocale = (char *(*)(int, char *))GetProcAddress(h, "setlocale"); __setlocale(LC_CTYPE, ""); __putchar = (int (*)(int))GetProcAddress(h, "putchar"); for (int i=0; i<sizeof(buf)-1; i++)...
-
I have tracked down the issue and found the problem caused by following code in mingw_pformat.c. /* Emit the data, converting each character from the wide * to the multibyte domain as we go... */ while( (count-- > 0) && ((len = wcrtomb( buf, *s++, &state )) > 0) ) { char *p = buf; while( len-- > 0 ) __pformat_putc( *p++, stream ); } When locale is set to Japanese, multi-byte char is not show correctly if it is not output in atomic. #include <stdio.h> #include <locale.h> void pr() { char buf[] = {0x83,...
-
Sorry, the comment is broken with above patch...
-
[patch] Stop to replace some special characters in file name for cygwin.
-
__mingw_printf() does not print non-ASCII chars correctly.
-
The hang of qt terminal in GNU Octave is also happen with gnuplot 5.2.8. So, This may be another problem. Ah, hang in 5.2.8 is not cleared even after several minutes, while the hang with revised initial patch for git master is cleared in several minutes. So, these may be not the same problem.
-
I had tested only with windows terminal. So, I have made tests for my initial patch and the patch tyan0-20220216.patch with qt and wxt terminal as well just now. Initial patch: qt terminal does not work at all. Revised initial patch (attached): qt terminal works with text interface, however, if using with GNU Octave (which passes binary data via stdin), the second plotting hangs. After several minutes hang, plotting window is occasionally updated to new plot. (windows and wxt terminal work fine both...
-
The patch is revised a bit.
-
Thanks for the patch. Unfortunately, the patch pipe-fix-v4.diff does not solve the issue. The problem is that fgets() in MyFGetS() (or fread() in MyFRead() for binary data) and fread() in stdin_pipe_reader() thread try to read the stdin pipe simultaneously after reading the lineplot '-' using 1:2 with linesp. I mean this issue by the race issue. Serializing threads was to prevent this race issue. However, I came up with the new patch attached. The idea is: only the stdin_pipe_reader() reads stdin...
-
Thanks for the patch. Unfortunately, the patch pipe-fix-v4.diff does not solve the issue. The problem is that fgets() in MyFGetS() (or fread() in MyFRead() for binary data) and fread() in stdin_pipe_reader() thread try to read the stdin pipe simultaneously after reading the lineplot '-' using 1:2 with linesp. I mean this issue by the race issue. Serializing threads was to prevent this race issue. However, I came up with the new patch attached. The idea is: only the stdin_pipe_reader() reads stdin...
-
Thanks for the patch. Unfortunately, the patch pipe-fix-v4.diff does not solve the issue. The problem is that fgets() in MyFGetS() (or fread() in MyFRead() for binary data) and fread() in stdin_pipe_reader() thread try to read the stdin pipe simultaneously after reading the lineplot '-' using 1:2 with linesp. I mean this issue by the race issue. Serializing threads was to prevent this race issue. However, I came up with the new patch attached. The idea is: only the stdin_pipe_reader() reads stdin...
-
Thanks for the patch. Unfortunately, the patch pipe-fix-v4.diff does not solve the issue. The problem is that fgets() in MyFGetS() (or fread() in MyFRead() for binary data) and fread() in stdin_pipe_reader() thread try to read the stdin pipe simultaneously after reading the lineplot '-' using 1:2 with linesp. I mean this issue by the race issue. Serializing threads was to prevent this race issue. However, I came up with the new patch attached. The idea is: only the stdin_pipe_reader() reads stdin...
-
Thanks for the patch. Unfortunately, the patch pipe-fix-v4.diff does not solve the issue. The problem is that fgets() in MyFGetS() (or fread() in MyFRead() for binary data) and fread() in stdin_pipe_reader() thread try to read the stdin pipe simultaneously after reading the lineplot '-' using 1:2 with linesp. I mean this issue by the race issue. Serializing threads was to prevent this race issue. However, I came up with the new patch attached. The idea is: only the stdin_pipe_reader() reads stdin...
-
This time I tried to verify by changing the number of CPU allocations in the virtual machine. CPU: Core i7-870 (2.93GHz) OS: Windows 10 1607 (Very old!) VM: VirtualBox 6.1.32 Number of allocated CPUs: Result (Probability) 1: Never occurs. (0%) 2: Sometimes occurs. (about 50%) 4: Always occurs. (100%)
-
This issue seems to depend on numbers of CPU cores. I tested again in my several PCs. Machine 1: CPU: AMD Ryzen 9 3950X (16 cores, 32 threads) Results: The issue always occurs. Machine 2: CPU: Intel Core i7-6700K (4 cores, 8 threads) Results: The issue always occurs. Machine 3: CPU: Intel Core i7-4790 (4 cores, 8 threads) Results: The issue always occurs. Machine 4: CPU: Intel Core i7-870 (4 cores, 8 threads) Results: The issue always occurs. Machine 5: CPU: Intel Core i5-M540 (2 cores, 4 threads)...
-
The patch in [#2491] is affected only when the terminal is not a console (when _isatty() returns 0). This seems to be a different problem.
-
Thanks for testing. "line 6: invalid command" error is also shown in my environment. Sorry for forgetting to mention that. I don't set GNUTERM environment, so qt terminal is used by default. However, the same happens with 'windows' or 'wxt' terminal.
-
Hmm, can anyone else reproduce the problem?
-
That's weird. I downloaded windows binary gp543-win64-mingw.7z from: https://sourceforge.net/projects/gnuplot/files/gnuplot/5.4.3/ I can reproduce the problem in my several environments constantly. What is the difference? I started gnuplot.exe inside command prompt (cmd.exe). Does type test.dem | gnuplot result the same?
-
Plotting data from stdin does not work properly.
-
Sorry, the updated patch still has problem. Revised again.
-
Sorry, the patch I posted first does not seem to work properly. The patch updated.
-
Plotting data from stdin does not work properly.
-
Sorry, the above patch still has problem. Revised again. Revised patch diff --git a/src/win/winmain.c b/src/win/winmain.c index 85c12c0c3..acce228c5 100644 --- a/src/win/winmain.c +++ b/src/win/winmain.c @@ -1105,8 +1105,9 @@ stdin_pipe_reader(LPVOID param) { do { unsigned char c; - size_t n = fread(&c, 1, 1, stdin); + size_t n; WaitForSingleObject(input_cont, INFINITE); + n = fread(&c, 1, 1, stdin); if (n == 1) nextchar = c; else if (feof(stdin)) @@ -1122,9 +1123,9 @@ HANDLE init_pipe_input(void)...
-
Sorry, the patch above does not seem to work properly. Updated patch diff --git a/src/win/winmain.c b/src/win/winmain.c index 85c12c0c3..549ec0156 100644 --- a/src/win/winmain.c +++ b/src/win/winmain.c @@ -1105,12 +1105,14 @@ stdin_pipe_reader(LPVOID param) { do { unsigned char c; - size_t n = fread(&c, 1, 1, stdin); + size_t n; WaitForSingleObject(input_cont, INFINITE); + n = fread(&c, 1, 1, stdin); if (n == 1) nextchar = c; else if (feof(stdin)) nextchar = EOF; + ResetEvent(input_cont); SetEvent(input_event);...
-
Plotting data from stdin does not work properly.
-
Due to this problem, gnuplot 5.4.3 (Windows binary) does not work properly with octave. Reverting the commit [e5f274] resolves the issue.
-
Segmentation fault occurs on substitution in 32-bit systems.
-
Segmentation fault occurs on undo.
-
I have confirmed that the issue has been fixed in the current git head. Thanks for working on this.
-
Due to this issue, gnuplot cannot be used as graphics toolkit for GNU octave any more.
-
If the handle passed to MsgWaitForMultipleObjects() is a pipe, it can response to pipe input, however, it does not response to window event. Timeout also does not work. No. I was wrong. MsgWaitForMultipleObjects() always returns WAIT_OBJECT_0 even if the pipe input is not ready when a pipe handle is passed.
-
The same issue happens with: (cat simple.dem; sleep 100) | gnuplot (echo plot x; sleep 100) | gnuplot If the handle passed to MsgWaitForMultipleObjects() is a pipe, it can response to pipe input, however, it does not response to window event. Timeout also does not work.
-
I wonder if it is the correct manner waiting for pipe handle using MsgWaitForMultipleObjects(). https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-msgwaitformultipleobjects says MsgWaitForMultipleObjects() cannot be used with pipe handle.
-
I found this issue occurs after the commit: commit 651af6267b0270a71c6e0c0c2345f2c01a68eea6 Author: Bastian Maerkisch bmaerkisch@web.de Date: Sat Jan 25 13:34:13 2020 +0100 Wait for pipe events without additional thread Previously, we would start a new thread for every single character in a pipe, making it very inefficient. This is not really necessary, we can just call MsgWaitForMultipleObjects() with the stdin handle directly. Bug #2204 Reverting this commit solves the issue.
-
Plot window freezes if stdin is not a console (Windows build).
1
