Console output and multithreading lazarus / 66-Unix ---------------------------------------------------------------------- zim · 2024-01-16 13:13 Hi Found some strange behaviour of Writeln in multithreaded app. It's a sort of debug mode (in normal operation it's all in logs), but really annoying. While on Windows all is ok, I expected use of critical section will help on Linux also, but not helped. Is there any working solution present ? The problem: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var Lock: TCriticalSection;procedure Log(S: String);begin  Lock.Acquire;  try  // ... some code with log rotating and output    Writeln(S);  finally    Lock.Release;  end;end; procedure Log is called many times from different code places, some in main thread, some from child threads. Expected output: log1 log2 log3 Actual output under Linux: log1            log2                                log3 ---------------------------------------------------------------------- Curt Carpenter · 2024-01-16 14:12 I would guess it's down to the different line endings used by win (\r\n) and linux (just \n) ---------------------------------------------------------------------- MarkMLl · 2024-01-16 15:01 Quote from: Curt Carpenter on January 16, 2024, 03:12:25 pmI would guess it's down to the different line endings used by win (\r\n) and linux (just \n) "Staircasing". However I've not seen that happen despite similarly having debug WriteLn()s called by multiple threads. i) If in doubt, put a Flush(Output) immediately after the WriteLn. ii) I've never had to use a critical section in that circumstance. iii) Where are you creating that critical section? iv) I /have/ seen peculiar effects if mixing references to Output and stdout. v) The only time I've seen staircasing like that is if I've intentionally messed around with terminal properties using ioctl(). Are you, by any chance, using something like the Crt unit elsewhere in the program? It's generally frowned upon to post a mere fragment, for precisely that reason: people can't see what you're doing before you get to the problem. MarkMLl ---------------------------------------------------------------------- cdbc · 2024-01-16 15:36 Hi I have "Staircasing" galore! I do use the Crt unit(+incs) and a home-made helper-unit:Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i // too big, please see attachment :o) Funny thing is, it was running happy along ...and still does  Yesterday I installed a new kernel in my lappy, upgrade from 5.16.19 to 6.5.13 After that, It all went to H*** in a handbasket when program ends?!? It ends ok, but back at the prompt, I can't see what I'm typing, and if I type "ls -l" (blind) + enter then the staircasing goes bananas  :'( I refuse to believe that it has to do with the kernel-upgrade. Regression to 5.16 is not an option, 'cause the new one is a lot faster  What to do? Regards Benny ---------------------------------------------------------------------- cdbc · 2024-01-16 15:42 Have a look-see  Regards Benny ---------------------------------------------------------------------- MarkMLl · 2024-01-16 17:08 Quote from: cdbc on January 16, 2024, 04:36:03 pmWhat to do? In your case    stty sane    and then start a new thread rather than hijacking this one. You will probably need to investigate the terminal defaults and what exactly the crt unit is doing on exit. My guess is that if you'd installed that kernel version as part of a new installation there would be something else in the distro handling the terminal differently... systemd is an easy target but there's so much that you're not telling us that it's impossible to say. MarkMLl ---------------------------------------------------------------------- cdbc · 2024-01-16 17:20 Hi No worries Mark, I didn't want to hijack anything, just wanted to show you an example of "staircasing"... It's the crt unit that's acting up, I'm solving it. As you were... Regards Benny ---------------------------------------------------------------------- MarkMLl · 2024-01-16 19:40 Quote from: cdbc on January 16, 2024, 06:20:03 pmNo worries Mark, I didn't want to hijack anything, just wanted to show you an example of "staircasing"... It's the crt unit that's acting up, I'm solving it. As you were... It's something I've seen very rarely since the days of Yggdrassil and kernel v2.x. MarkMLl ---------------------------------------------------------------------- marcov · 2024-01-16 21:49 Crashes in the textmode IDE sometimes also cause this. ---------------------------------------------------------------------- MarkMLl · 2024-01-16 22:01 Quote from: marcov on January 16, 2024, 10:49:39 pmCrashes in the textmode IDE sometimes also cause this. Because the kernel hasn't been sent the ioctl() (or sequence thereof) to restore cooked mode. Except for test programs that were deliberately courting this behaviour https://github.com/MarkMLl/serialcomms/blob/main/Term.pas I've really seen this very little over the last 30 years. Except for one particular development environment based on Eclipse... I forget the details, and if they didn't take my bug report seriously then it's hardly my problem. MarkMLl ---------------------------------------------------------------------- zim · 2024-01-17 11:43 Actually starcasing is not the only problem. Nearly at the very beginning of my log I constantly see some unicode corription also. It's quite surprising - every time at the same place and exactly at the same character. Line is somehow broken at that character, and instead of the character an asterisk symbol is shown. While same output written to the log files has no problems. Forced Flush has no effect. So, seems there're still some deep problems with console buffers and it's not thead safe. Well, I can see the only solution - to make custom class for console output that will do in-memory buffering and a single physical output point.