elimination to our bytecode compiler. Also iterate it to a fixpoint.
Last, add a total instruction counter during bootstrap so we can easily
see how many instructions are in the core library.
These simple passes were factored out of some more involved bytecode
optimization work as easy wins without much code.
Some further research also suggests that this is well know limitation of
winsock and failure to call this in combination with ConnectEx can be a
problem.
However, I cannot reproduce locally on my windows machine. Searching
suggests a timing error within the network stack - if we call net/
functions before the connect is actually setup, it will be in an invalid
state.
* Fix a couple of imprecisions in the file/ docs
The `+` flag to `(file/open)` was incorrectly documented as being for
appending. Instead, this allows to read to files opened with `:w` or
`:a`, and to write to files opened with `:r`. This is the same as the
`+` flag in `fopen(3)`.
The `(file/seek)` function was documented as having both `whence` and
`n` as optional arguments. It also didn't say what the default for `n`
was. Anyway, this doesn't make sense, as a default of `:cur` and `0`
would effectively make `(file/seek f)` a no-op. I also amended a test so
both `(file/seek f :set 0)` and `(file/seek f :set)` are covered and
checked to move to the beginning of the file.
* Remove useless check for argc >= 2
We already determined it is between 2 and 3 with `janet_arity(argc, 2, 3)`.
* Dump args in assertion
* Unroll loop in test
* Differentiate failure messages
I encountered this issue with `janet -e '(os/shell "echo")'` on Mac, system malloc lib will complain as follows:
```
janet(42817,0x7ff854547780) malloc: *** error for object 0x60000000b730: pointer being freed was not allocated
janet(42817,0x7ff854547780) malloc: *** set a breakpoint in malloc_error_break to debug
```
So I followed the suggestion and here's the backtrace:
```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x00007ff810cb6883 libsystem_malloc.dylib`malloc_error_break
frame #1: 0x00007ff810ca76d3 libsystem_malloc.dylib`malloc_vreport + 761
frame #2: 0x00007ff810caab31 libsystem_malloc.dylib`malloc_report + 151
frame #3: 0x0000000100025402 janet`janet_ev_default_threaded_callback(return_value=JanetEVGenericMessage @ 0x00007ff7bfefad90) at ev.c:2412:13 [opt]
frame #4: 0x0000000100024b1f janet`janet_loop1_impl [inlined] janet_ev_handle_selfpipe at ev.c:1643:13 [opt]
frame #5: 0x0000000100024ac9 janet`janet_loop1_impl(has_timeout=<unavailable>, timeout=0) at ev.c:2028:13 [opt]
frame #6: 0x0000000100024714 janet`janet_loop1 at ev.c:1588:13 [opt]
frame #7: 0x00000001000497f5 janet`janet_loop_fiber at ev.c:1609:41 [opt]
frame #8: 0x00000001000497b3 janet`janet_loop_fiber(fiber=0x0000600002903790) at run.c:150:5 [opt]
frame #9: 0x0000000100075266 janet`main(argc=<unavailable>, argv=0x00007ff7bfeff210) at shell.c:1284:14 [opt]
frame #10: 0x00007ff810b1041f dyld`start + 1903
```
Found out that it's actually a missing break in the code which leads to double free.
BTW, I'm thinking that if we can implement a debug allocator to be used in the test, so maybe this kind of bugs can be captured earlier.
Change-Id: I74d324b70b39ddc7d6f509b0382e2be36a6a6964
Signed-off-by: Tw <tw19881113@gmail.com>
on 32 bit systems in some cases.
Since most internal arrays in Janet have 32 bit limits, this is is not
hit in practice on 64 bit systems, except in cases of user input. Apply
a fix more generally to simply avoid the issue by coding "defensively".
Some applications are not strictly needed.
Also match shell convention, with strict searching from left to right
instead of right to left by default. The _first_ element will be bound
to (dyn *syspath*), not the last.
Potentially breaking change for complicated, custom setups
Calvin Rose