-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiler segfaults #2
Comments
Thanks for reporting the issue, it is a known issue but still. This isn't really a major issue since recursive tuples don't make much sense anyway. |
I'm not sure I understand why recursive tuples shouldn't make sense. Tuples seem to be similar to C structs, which can and should be recursive. What's the difference between tuples and objects in Nimrod that means objects can contain references to themselves, but tuples can't? Why, e.g., does this not make sense:
BTW, here's the simplest code I can find that causes the problem:
|
Well, tuples can be recursive, it's just that the compiler does not support them yet and thanks to objects it's easy to work around this bug for now. |
Ah, OK. |
# This is the 1st commit message: default last in strutils.find to -1 # This is the commit message nim-lang#2: Revert "default last in strutils.find to -1" This reverts commit 3a99556. # This is the commit message nim-lang#3: add openArray variable of find with SkipTable # This is the commit message nim-lang#4: add find method that accepts an openArray # This is the commit message nim-lang#5: add tests # This is the commit message nim-lang#6: Revert "add find method that accepts an openArray" This reverts commit 2ab5351. # This is the commit message nim-lang#7: Revert "add openArray variable of find with SkipTable" This reverts commit 58159fc.
# This is the 1st commit message: default last in strutils.find to -1 # This is the commit message nim-lang#2: Revert "default last in strutils.find to -1" This reverts commit 3a99556. # This is the commit message nim-lang#3: add openArray variable of find with SkipTable # This is the commit message nim-lang#4: add find method that accepts an openArray # This is the commit message nim-lang#5: add tests # This is the commit message nim-lang#6: Revert "add find method that accepts an openArray" This reverts commit 2ab5351. # This is the commit message nim-lang#7: Revert "add openArray variable of find with SkipTable" This reverts commit 58159fc.
# This is the 1st commit message: default last in strutils.find to -1 # This is the commit message nim-lang#2: Revert "default last in strutils.find to -1" This reverts commit 3a99556. # This is the commit message nim-lang#3: add openArray variable of find with SkipTable # This is the commit message nim-lang#4: add find method that accepts an openArray # This is the commit message nim-lang#5: add tests # This is the commit message nim-lang#6: Revert "add find method that accepts an openArray" This reverts commit 2ab5351. # This is the commit message nim-lang#7: Revert "add openArray variable of find with SkipTable" This reverts commit 58159fc.
# This is the 1st commit message: default last in strutils.find to -1 # This is the commit message nim-lang#2: Revert "default last in strutils.find to -1" This reverts commit 3a99556. # This is the commit message nim-lang#3: add openArray variable of find with SkipTable # This is the commit message nim-lang#4: add find method that accepts an openArray # This is the commit message nim-lang#5: add tests # This is the commit message nim-lang#6: Revert "add find method that accepts an openArray" This reverts commit 2ab5351. # This is the commit message nim-lang#7: Revert "add openArray variable of find with SkipTable" This reverts commit 58159fc.
* remove nimble packages * remove unused code * tests are green on my machine :D
187: debug: clean up formatting for the vmgen debugging r=saem a=haxscramper - Improve formatting for the vmgen code listing reports - Split VM debuggint defines in two - `nimVMDebugExecute` to trace actually executed vm opcodes, and `nimVMDebugGenerate` to see generated code. - Allow filtering out generated code by proc name, using `--define:expandVmListing=vmTarget` ```nim type Obj = object charField: char intField: int proc vmTarget(arg: Obj) = echo arg.charField.int + arg.intField static: vmTarget(Obj()) ``` ``` nim c --filenames:canonical --define:expandVmListing=vmTarget file.nim ``` ``` Code listing for vmTarget LdConst r3 $ 1279 system.nim(2005, 30) LdObj r6 r1 r0 file.nim(7, 11) NodeToReg r5 r6 r0 file.nim(7, 11) Conv r6 r5 int char file.nim(7, 21) LdObj r7 r1 r1 file.nim(7, 31) NodeToReg r5 r7 r0 file.nim(7, 31) AddInt r4 r6 r5 file.nim(7, 26) IndCallAsgn r2 r3 nim-lang#2 file.nim(7, 26) Echo r2 r1 r0 file.nim(7, 26) Ret r0 r0 r0 file.nim(7, 8) Eof r0 r0 r0 file.nim(7, 8) ``` 188: separate documentation publishing from building r=saem a=alaviss Since docs were published as a part of the main CI run, we were forced to re-run CI on devel even though bors has performed the check and built the documentation. This wastes resources especially since our test matrix is expanding. This commit implemented a separate publisher that publishes artifacts built during staging (currently docs). The publisher uses a pull architecture, that is, to query producers and obtain necessary artifacts from them. Main CI will now always build and upload generated documentation, which has a nice bonus of allowing us to review docgen changes more throughly in PRs. An another adjustment made is that the "Edit" link will now be hard-coded to the `devel` branch instead of being inferred from the branch being built on. This lets us reuse docs built during the time spent in staging branch. Closes nim-lang#182 Co-authored-by: haxscramper <haxscramper@gmail.com> Co-authored-by: Leorize <leorize+oss@disroot.org>
tlsEmulation:on under NetBSD-10Beta and NetBSD-current produces an executable which crashes immediately as follows: Core was generated by `koch'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000047b4c2 in nimZeroMem () (gdb) bt #0 0x000000000047b4c2 in nimZeroMem () nim-lang#1 0x00000000004897b2 in threadVarAlloc__system_2162 () nim-lang#2 0x000000000048980e in initThreadVarsEmulation () nim-lang#3 0x0000000000489848 in PreMain () nim-lang#4 0x000000000048986a in NimMain () nim-lang#5 0x00000000004898a9 in main () I can't speak about the other BSDs.
tlsEmulation:on under NetBSD-10Beta and NetBSD-current produces an executable which crashes immediately as follows: Core was generated by `koch'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000047b4c2 in nimZeroMem () (gdb) bt #0 0x000000000047b4c2 in nimZeroMem () #1 0x00000000004897b2 in threadVarAlloc__system_2162 () #2 0x000000000048980e in initThreadVarsEmulation () #3 0x0000000000489848 in PreMain () #4 0x000000000048986a in NimMain () #5 0x00000000004898a9 in main () I can't speak about the other BSDs.
tlsEmulation:on under NetBSD-10Beta and NetBSD-current produces an executable which crashes immediately as follows: Core was generated by `koch'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000047b4c2 in nimZeroMem () (gdb) bt #0 0x000000000047b4c2 in nimZeroMem () #1 0x00000000004897b2 in threadVarAlloc__system_2162 () #2 0x000000000048980e in initThreadVarsEmulation () #3 0x0000000000489848 in PreMain () #4 0x000000000048986a in NimMain () #5 0x00000000004898a9 in main () I can't speak about the other BSDs. (cherry picked from commit e9ed090)
tlsEmulation:on under NetBSD-10Beta and NetBSD-current produces an executable which crashes immediately as follows: Core was generated by `koch'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000047b4c2 in nimZeroMem () (gdb) bt #0 0x000000000047b4c2 in nimZeroMem () nim-lang#1 0x00000000004897b2 in threadVarAlloc__system_2162 () nim-lang#2 0x000000000048980e in initThreadVarsEmulation () nim-lang#3 0x0000000000489848 in PreMain () nim-lang#4 0x000000000048986a in NimMain () nim-lang#5 0x00000000004898a9 in main () I can't speak about the other BSDs.
Experimenting with Nimrod today, I was able to make the compiler segfault by attempting to compile:
This code is nonsense, but on the principle that the compiler should never segfault, I'm suggesting this is a bug. I'm not certain what in the code is causing it, but it seems to at least require: the tuple (the equivalent object does not cause a segfault), the recursive reference in the tuple, and the recursive proc.
Nimrod was compiled on Ubuntu 10.04, on an AMD-64 architecture. I'm compiling the above code like so:
The text was updated successfully, but these errors were encountered: