mbit90

Yep my needs are clearly different. I'm just trying to stick to the topic, which is about the very simple example code in my first post, and that it should be working according to the help file, while it causes autoit to deadlock. Good night to you as well.

Well, assume you want the reading of stdout to be fast, then you could not use Sleeping, but you would have to rely only on Locks and Busy waiting. Looking at this from a C programmer perspective. i get the truncation of the tasklist output only if I remove the Sleeps from your code, and it's perfectly clear why. The last loop... ... without the Sleep will collect some initial output into the string, but in the second iteration, StdoutRead returns "" (most likely) and the loop exits (perhaps) without the remainder of output that tasklist has yet to print. It depends on the timing between the two processes and thus has undefined behaviour.

I don't get the full Tasklist output with the Sleeps removed - code like this must not rely on getting the Sleep timings just right. You can't just assume that when StdoutRead returns an empty string once, that the output is finished. More output may come later. Of course it works with tasklist followed by 500ms of sleeping - in the common case. The only (intended) reliable indication for end-of-stream seems to be @error after StdoutRead, or am I missing something?

Hmm... so you inserted a watchdog sort of thing into the loop, in case StdoutRead does not give @error when it should. Nice idea. However, when I run it, it just freezes again instead of giving the $y=500001 outputs. AutoIT does not accumulate any cycles when I check in Process Hacker, meaning it's not stuck in a loop, but an actual deadlock. @TheXman, your example works just fine for most applications, but the point of my original post was to demonstrate that AutoIT freezes when calling StdoutRead in a loop. Calling StdoutRead in a loop is mentioned as good practice in the help file, so it should not cause the runtime to deadlock. Furthermore, as you mentioned, there might be reasons to "stream" the output to the host application continuously. I currently build such an application and stumbled upon this bug, then constructed the minimal example to isolate the issue. I might not have made this clear in my original post, if so, I'm sorry This was meant to be a bug report, kind of. Is there a better way of reporting this issue to the devs? I'm still interested in any intermediate workarounds that call StdoutRead repeatedly without freezing though cheers

Nope, not SCiTE freezes, the AutoIT process (the runtime interpreter) freezes. And no crashes. A freeze means the program stops doing anything, it deadlocks, and becomes unresponsive (e.g. the try icon dos not react to anything in this example). You can in fact see the same result without running in SCite but directly. You just don't get the ConsoleWrite() output. $str is not defined. But when I remove $str, Autoit Crashes after a few minutes with a DialogBox saying "Error allocating memory", which is also strange but surely a different bug? When I tried this, AutoIt froze again, but the last console window that popped up closed. However, tasklist.exe still ran. Terminating tasklist.exe did not un-freeze AutoIt. Note that the call to ProcessWaitClose($pid) does not cause the issue -- it can be removed from the script with the same result. It's just there for 'best practice' reasons. It's also not tasklist.exe misbehaving in some way, I tried this with other console applications as well with the same result.

I have run into a problem with Run(..., $STDOUT_CHILD) and then calling StdOutRead($pid) in a loop to get all data. I'm starting the same child application over and over, collecting and then evaluating the child's output. At a certain point Autoit freezes. It appears to be a random deadlock. The deadlock does not happen when I do ProcessWaitClose($pid) and afterwards StdOutRead($pid). But the helpfile says it's advisable to read STDOUT in a loop to get all data. Here's the minimum example code. Make sure to watch the console output e.g. in SCiTE. It will stop spewing new output after a few seconds or minutes: ; AutoIt Version: 3.3.14.2 ; Script Function: Autoit sometimes deadlocks (stops responding) when using Run() repeatedly with a StdoutRead loop. ; Just leave this running for a certain time, it will freeze eventually. #include <AutoItConstants.au3> While True $pid = Run('tasklist.exe', @ScriptDir, @SW_HIDE, $STDOUT_CHILD) $sOutput = "" Do $sOutput &= StdoutRead($pid) ; collect new output Until @error ; EOF reached ProcessWaitClose($pid) ; These two don't make a difference... StdioClose($pid) ; ... you can leave them out ConsoleWrite($sOutput) Sleep(50) WEnd Am I doing something wrong here or is there a bug in AutoIT?

Update: Jos' answer to the topic you linked actually helped. It turns out that when started through the explorer context menu, SciTE did not get the SCITE_USERHOME env variable. That's because explorer's environment was outdated and did not have the variable, and SCiTE inherited that environment. So I "restarted" all explorer.exe instances and that solved it Thanks for the help! /close

Hey thanks for your reply. Checked the version numbers - they are the same. They must be, it's the same program after all. I checked in task manager, it's the same executable running in both cases. I don't have any other copy of Scite installed.

Hello, first post here, but I've been using Autoit since around 2010. I just upgraded to Autoit 3.3.14.5 and SciTE4AutoIt3 07_11_2019. Had been using an ancient version from 2015 before. I'm on WIn7 64 bit. I don't like the current syntax highlighting colors so I fired up SciteConfig, but it does not change the colors and fonts after hitting Apply. Then I went to Menu Options -> Open User Options File, it opens the SciTEUser.properties file in the program directory - which is not writeable when UAC is enabled. As soon as I give myself write rights (set ACLs), scite will delete that file. So that's not the solution. I had been opening Scite from the context menu of a script in Explorer all this time. Then I started scite from the Start Menu shortcut -- and now it uses the config files from the userprofile (C:\Users\xxx\AppData\Local\AutoIt v3\SciTE) and SciteConfig works like a charm. So why does Scite work so differently when started from the context menu? How do I fix this?