BMK makemods - error reading from stream #54
Comments
|
Same of course happens for "pub.mod" too ... |
|
I tried to build that BMK in "gdb debug mode" (so it contains the gdb information) but then I receive a "Program does no longer work" error when trying to compile a module. I receive that error too, when just running "bmk.debug.exe" - right after it finishes outputting the "available commands" it appends a Edit: I compiled the code with BCC/BMK from last month, so not most current one. |
|
Executing it without "debug" I receive a SIGSEV/segfault. Backtrace of course only contains "??" entries. |
|
"Error reading from stream" is a TStreamReadException. |
|
Ok ... compiled 20x successful - renamed my brl.mod and used another brl.mod ("brl.mod_newTimer" renamed to "brl.mod" then). It's a bit hard to "read" as the output is garbaged because of the threaded output... |
|
Above is another example why I suggested some kind of "mutex" for the output - so stuff wont interfer. Edit: but as it mixes different processes (BMK calls multiple BCCs) it is surely not that trivial to implement - as each BCC instance should have access to a "bmk defined" mutex. Dunno how this is done normally - only simple solution would be some kind of ".lock" file which is there as long as a process is outputting "a bunch of lines" (so its own "text block"). |
|
Ideally, one would use Pub.FreeProcess to handle the output, but currently bmk relies on exit codes from processes to decide whether a particular command was successful or not. |
|
Maybe we should have a flag to disable multi-processing? Something like |
|
Can you confirm that forcing "-single" mode on the build fixes the issue? |
|
With BMK/BCC build last week I do not get the read-error (just the mixed output of the external commands...which does not happen with Will close for now. If it happens again I will reopen |
|
Just received it again - with:
Excuse the wall of text: I assume it is some kind of race condition - something is building files in a threaded manner - and then, bamm, thread A not finished yet so the desired file is still missing. Edit: of course building it again (so now some files were precompiled properly) it does not fail there anymore. And yes, "wxgppanel.mod" is no longer supported but I manually copied it in (as I still use it until I replace it with the wxmathplot.mod). Wonder why this "wxgppanel.mod" had to be compiled again (somehow with newest BCC this tooks a "feels longer" time) - maybe because the final files were not created before the Maybe it would be a good idea to pass the stream URI in the error message - would be less abstract then. |
|
Hmmm might it be that this race condition issue is also the source of the bug described there in issue #88 ? Assume that some build files are generated in threads ... now the main file which only "imports" other files (so "source compilation" can take place and only during linking it is important to have the files there) is created before that other files_. Now you switch on "quick compile" and it checks timestamps - and sees that certain files are newer than others - and now BMK thinks it should recompile them. Just did a "quick compile" after it built successfully - and it recompiled some files (max2d.bmx and wxtimer.mod - and some others). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On that particular Windows 7 computer (which has issues with the timer ....) I sometimes have "error reading from stream" when compiling the modules (
bmk makemods -a -r brl). The error either happens right inbetween (so output is something like "[ 3%] Processing:driv error reading from streamer" - so mixed "driv..er") or right after such a processing line.I then run the command again - and it fails at another module or happily continues until it finished. So something seems to interrupt file access. It is a intel based computer, maybe threading issues or so?
The text was updated successfully, but these errors were encountered: