IRC channel logs

2020-06-18.log

back to list of logs

<dsmith-work>Just visually inspecting the code, all gets seem to have matching ungets.
<rekado>rebasing guile-emacs on top of Emacs 25 now. It’s not exactly fun, but it’s a great way to get familiar with the changes.
<RhodiumToad>I can't tell whether what I'm seeing is a debug artifact or is real
<dsmith-work>RhodiumToad: Could be a wild pointer smashed it. But my reading of the code says it can ony ever be 0 1 (or 2 for arm,aarch64)
<RhodiumToad>what gdb is telling me is that the _jit is pointing to the wrong place
<RhodiumToad>ok. that does turn out to be a debug artifact.
<RhodiumToad>ASSERT(!(im & 0xfbff8f00)); in torri() is where it dies.
<RhodiumToad>im is 256.
<RhodiumToad>sigh
<RhodiumToad>I may have found it
<RhodiumToad>the nasal demons strike again
<RhodiumToad># define rotate_left(v, n) (v << n | v >> (32 - n)) /* spot the problem */
<RhodiumToad>tum te tum, waiting for eval.go to compile again
<rlb>Why does this print bar twice? (define-syntax foo (begin (display "bar\n") (identifier-syntax 1)))
<justin_smith>rlb: could this be similar to the semantics that make eval-when neccessary?
<justin_smith>eg. the define-syntax is executed twice when entered at the repl, maybe
<rlb>Ahh, I suppose that might be it.
<rlb>Thanks. I'll poke around a bit more.
<justin_smith>I don't know your actual case, but it might help to consider using eg. a delay to make some side effect only evaluate once
<rlb>In this case, I want to define a syntax (maybe an identifier syntax) that captures a binding.
<rlb>Though I still need to think through whether or not that really makes sense here...
<RhodiumToad>anyone want to bet on whether this compile succeeds?
<RhodiumToad>(currently 36 minutes into the compile of psyntax-pp)
<daviid>it will succeed
<daviid>it make couple of hours on old machines ...
<RhodiumToad>well that depends on whether my fix for the above bug is correct :-)
<RhodiumToad>this is on an RPI2b
<daviid>if your bug fix is a fix and not a bug :):) i bet it will compile
<RhodiumToad>yawn
*RhodiumToad will leave it compiling :-)
<minerjoe>I'm hoping this is a channel to just shoot from the hip?
<minerjoe>I'm new to guile and trying to add it to an existing program. I'm trying to call a function defined in the main program (not a shared library). The symbol is present via "readelf -sW" as GLOBAL DEFAULT, but it is not found via (dynamic-func "foo" (dynamic-link)). Maybe this is not the way to get at a function not dynamically linked into the program?
<daviid>if i wanted to measure the impact of replacing map by a generic, what would be a good micro benchamrk?
***emacsoma1 is now known as emacsomancer
<dsmith>RhodiumToad: What is your fix?
<dsmith>RhodiumToad: What problems do you see in that rotate macro?
<dsmith>The args are unsigned. And single names. And it's for a 32bit arm.
<dsmith>The one call site loops < 32, so no "overrotate".
<wingo>greets
***apteryx is now known as Guest68790
***apteryx_ is now known as apteryx
<RhodiumToad>dsmith: the rotate macro has an undefined result when n is 0
<RhodiumToad>ok, so after fixing the bug the compile completed
<wingo>RhodiumToad: wow!
<wingo>excellent debugging!!
<wingo>we should have a way to build with ubsan :P
<RhodiumToad>what I did was add if (v <= 0xFF) return v; and change the loop to start from 2 rather than 0
<RhodiumToad>other options would be to use v >> ((32 - n) & 31) or a compiler rotate intrinsic
<RhodiumToad>did you see my other comment about nonportable use of `date` ?
<mauritslamers>hey all, I have a question regarding style or best practices. I am writing something in guile within the context of Lilypond. It is not part of the project at all, but it uses the context it gives for additional output. My question is not how to use the Lilypond API, but more on what the best approach is datawise. Lilypond seems to be using mainly assoc lists to keep track of things. Now I am contemplating whether to use assoc-lists as a main
<mauritslamers>vehicle for storing additional info, or to use object properties.
<mauritslamers>My own background is mainly JS, so I am used to construct these kinds of systems from a semi-funcitional, semi-OO point of view.
<RhodiumToad>wingo: I'm going to try a build with clang -fsanitize=undefined :-)
<wingo>RhodiumToad: saw the comment, didn't look into it
*wingo has v little time lately, for family reasons
<mauritslamers>Basic task is to retrieve a list of events, parse these events in a certain way, so they create output. The exact output however depends on circumstances (such as previous events and future events). My current approach is to leave everything in a big list of assoc-lists, change values where necessary. But I am wondering whether I should use object properties instead to keep track of these extra settings, and what the advantages are of object
<mauritslamers>properties vs assoc lists
<RhodiumToad>assoc lists don't perform especially well, imo
<wingo>assoc lists are fine if there are few elements in them tho
<janneke>RhodiumToad: there used to be a ... yeah "it depends", last time i looked it was ~100 elements
<wingo>basically i would use either alists or hash tables. object properties use weak hash tables underneath, which is good if you know you don't want to keep the object alive
<mauritslamers>The easiest for me would be to use object properties, it would lead to me writing something that essentially would be JS but with a Scheme syntax :)
***dozzie_ is now known as dozzie
<wingo>but hash tables can be iterated over
<wingo>hehe
<wingo>yeah, sorry, no concrete guidance here ;)
<mauritslamers>In JS I have the certainty that when I change an object, I will always keep the pointer (reference) to that object. I gathered from the docs that this guarantee doesn't hold with assoc-set!
<mauritslamers>as in: when assoc-set! is used on a list while setting a new key, you get a different reference (pointer) back.
<mauritslamers>wingo: no worries, it is more curiosity about what would be the more scheme way of doing things instead of JS.
<wingo>yeah, can be interesting experimenting with different ways of writing a program, whether you build up a mapping in a functional way, or whether you use a more place-oriented approach of stuffing new associations in a hash table or whatever
<mauritslamers>The biggest issue is that I might have to reverse course somewhere in the program. This big list of events consists of multiple streams (musical staffs to be exact). In most of the situations everything of importance stays within a single staff, but there are situations where I suddenly need to access info on a different staff, ie different stream.
<mauritslamers>So, technically i could split it up in as many lists as there are staffs and process each list individually
<mauritslamers>It would cause issues though when it turns out I do need info from a different staff.
<mauritslamers>The functional way would be to split it up, and return parsed lists for each staff
<mauritslamers>The JS or OO way would be to leave it as a single list, filter it out per staff, and adjust settings, but that works on the assumption that the pointers / references to these list items would not change.
*RhodiumToad not sure that there is a "the" functional way
<RhodiumToad>now bootstrapping eval.go with -fsanitize=undefined
<RhodiumToad>let's see if this works.
<chrislck>hola!
<chrislck>What level schemer are you?
<chrislck>1. I'm a pythonista. I like my for loops.
<chrislck>2. I'm scheme-curious. What's all this about cons car cdr?
<chrislck>3. Wow. I love srfi-1!
<chrislck>4. macros? WTH is this supposed to work
<chrislck>5. Holy amaze-balls! I love named let.
<chrislck>6. srfi-1 can kiss my ass, ice-9 match ftw
<RhodiumToad>well, -fsanitize=undefined has made the compiler a hell of a lot slower
<RhodiumToad>used to take 30 mins to compile eval.go, it's now on 49 minutes and not done yet
<mauritslamers>chrislck: if you were talking to me: not really on that scale. I know about macros, I know what they do. So conceptually I sort of know the roots of the language but I simply do not have the experience of designing with it
<mauritslamers>So for me the question above is mainly about how I can "prevent" myself to starting writing JS in scheme syntax :)
<mauritslamers>What I have seen so far with Guile is that using assoc lists and writing functions to change things very much resembles the way C deals with objects: structs to hold the data, methods/functions/procedures to change things on that struct.
<RhodiumToad>what kinds of objects are you referring to?
<mauritslamers>C has structs to keep data, and uses externally defined functions / methods to change data inside structs of that type
<mauritslamers>Thinking about this a bit longer I think my question is mainly how to deal with state and state changes in scheme
<RhodiumToad>records in scheme are like C structs. goops objects are more... objecty
<mauritslamers>and whether that is different from language x
<mauritslamers>important for me at this moment is also that what I write has to work with a very old version of guile (1.8.2), as it runs as part of Lilypond 2.14
<RhodiumToad>ah
<mauritslamers>and it is a bit complex for me to figure out what is supported there exactly.
<chrislck>maybe you can be the driving force to move on to guile-2.2 :)
<RhodiumToad>or even guile-3
<mauritslamers>Let me spill all the beans, that will make it easier :)
<mauritslamers>I am working on music braille support for Lilypond, not as part of the Lilypond project.
<mauritslamers>The music basis of it atm is the song bundle of the dutch protestant churches, of which a new version has been made using Lilypond 2.14
<chrislck>are you the mauritslamers who hangs in #gnucash too?
<mauritslamers>yes :)
<mauritslamers>because of many reasons, not in the least that I am the one and only dev on this project, it is not possible timewise to convert either Lilypond guile to something more recent, or to try to convert that song bundle to a more recent Lilypond version.
<mauritslamers>chrislck: now you mention it I recognize your nick :)
<mauritslamers>and IIRC RhodiumToad also frequents #postgresql?
<mauritslamers>That nick is also very familiar at least :)
<mauritslamers>anyway: I have already written something that does at least a partial braille conversion, but I am now redesigning and refactoring because of the limitations of the current implementation.
<mauritslamers>So I am mostly trying to figure out how to design this in a way that it works as fluent as possible within guile, instead of trying to imprint the semantics and methods of different language on this.
<mauritslamers>What I find perhaps the most complex is how to do list navigation: I am parsing a list and I need to walk backwards and forwards in that list in order
<mauritslamers>to figure out the context of the item I am currently processing
<mauritslamers>in JS I would use an array and indexes, and use properties on objects to keep the context data on, and create a method to render the required braille for that object
<mauritslamers>But that doesn't really work that way in scheme
<chrislck>use for-each, or preferably named let
<chrislck>scheme lists are not designed for random access
<mauritslamers>would vectors be a solution there?
<chrislck>yes, but as usual, it depends. how often you expect to access elements randomly?
<chrislck>best pastebin your snippet
<mauritslamers>Hmm, I don't see how I can make this into a pasteable snippet: Lilypond creates events, and from these events I create a list (currently) of all events. In that list I expect to access elements randomly a lot, as well as filter them based on different properties or settings.
<mauritslamers>what I have been doing now is using for-each, and then through a closure keep track of the previousNoteEvent or previousEvent
<mauritslamers>which are changed through set!
<chrislck>as usual, "it depends"
<chrislck>TMTOWTDI
<dsmith>RhodiumToad: "<< 0" Should be fine, So ">> (32-0)" is undefined behavior?
<RhodiumToad>if x is a 32-bit type, x >> 32 is undefined
<dsmith>RhodiumToad: What bug was this?
<RhodiumToad>this shows up when doing jit on arm, it's in lightening/arm-cpu.c
<dsmith>Right. Wondering if its the "random" segfaults I'm seeing.
<RhodiumToad>for me the result was that it would work apparently fine up to language/cps/compile-bytecode.go and then abort on that
<dsmith>Consistently?
<RhodiumToad>yes
<dsmith>Ah
<dsmith>So that's probably clang-specfic?
<RhodiumToad>well it's undefined behavior in any compiler
<RhodiumToad>the specific way in which the undefined behavior manifests itself can vary, of course
<dsmith>Yes
<RhodiumToad>generating bad jitted code is certainly possible
<RhodiumToad>anyway, you could try fixing it and testing again on arm, see what happens?
<dsmith>Yes definitely
<RhodiumToad>my sanitize=undefined build has ground its way through psyntax-pp successfully and is now working through the other files
<RhodiumToad>it's at least 2x slower than normal
***terpri__ is now known as terpri
***rekado_ is now known as rekado
<rekado>rebased 25 of 159 commits for guile-emacs
<rekado>lots of them are really big commits
<rekado>this is going to take a while…
<civodul>fearless rekado strikes again! :-)
<dsmith-work>Thursday Greetings, Guilers
<dsmith-work>RhodiumToad: Nope. Still fails for me.
<RhodiumToad>huh.
<chrislck>mauritslamers: nothing beats looking at your code directly
<RhodiumToad>fails how exactly, and what exact sequence of events?
<dsmith-work>running the test-language in isolation repeatedly until segfault.
<dsmith-work>with the jit threshold at 0
<dsmith-work>while GUILE_JIT_THRESHOLD=0 make TESTS=test-language check-TESTS; do :;done
<dsmith-work>One kind of failure:
<dsmith-work>(gdb) bt
<dsmith-work>#0 0x76f505cc in scm_is_string (x=0x0) at strings.h:293
<dsmith-work>#1 scm_string_to_symbol (string=0x0) at symbols.c:361
<dsmith-work>#2 0x722df4cc in ?? ()
<dsmith-work>Backtrace stopped: previous frame identical to this frame (corrupt stack?)
<RhodiumToad>ok. I'll try that when this build is done.
<dsmith-work>And I've been running gdb like this:
<dsmith-work>../../meta/uninstalled-env ../../libtool --mode=execute gdb ../../libguile/guile core
<dsmith-work>From the test-suite/standalone dir
<dsmith-work>jit_new_state takes an allocation and a free function.
<dsmith-work>Called with an allocate that is scm_gc_malloc
<dsmith-work>The free funcion is a nop.
<dsmith-work>Would it be better to use scm_gc_free ?
<RhodiumToad>presumably there's a reason not to
*RhodiumToad hasn't dug into the code much yet
<rekado>I see no stable-3.0 branch. Is that role taken by the master branch?
<civodul>yes
<civodul>dsmith-work: you're seeing that with master on ARMv7?
<dsmith-work>Yes
<dsmith-work>Well, v3.0.2-141-g2e2e13c40
<civodul>ouch, so we're not done yet there
<civodul>i never hit that though, weird
<dsmith-work>Does not happen every run.
<dsmith-work>So...
<dsmith-work>location specfic? Using uninitialized memory?
<dsmith-work>jit threshold=0
<dsmith-work>Never happens without the jit. So something arm jit specific.
<dsmith-work>So is there any advantage to calling scm_gc_free()? (I'm thinking yes)
<RhodiumToad>gmake[2]: *** [Makefile:2279: ice-9/and-let-star.go] Segmentation fault (core dumped)
<RhodiumToad>looks like it's in generated code
<RhodiumToad>=> 0x22ba90a8: ldrt r5, [r12]
<RhodiumToad>r12 is 0
<RhodiumToad>in fact,
<RhodiumToad> 0x22ba90a4: mov.w r12, #0
<RhodiumToad>no useful backtrace
<dsmith-work>So does that look like bad generated code?
<RhodiumToad>this one looks like it is not completely reproducible
<RhodiumToad>well, hard to say.
<RhodiumToad>hm.
<dsmith-work>Does a disassm of the surrounding code look reasonable?
<RhodiumToad>the disasm of _that_ code doesn't look reasonable.
<RhodiumToad>why ldrt?
<dsmith-work>Maybe look at it as thumb code instead?
<RhodiumToad>I wonder if this is some confusion over arm vs. thumb mode
<RhodiumToad>how do I convince gdb to do that? I've not used it much on arm, yet
*dsmith-work looks for his notes...
<dsmith-work>set arm force-mode thumb
<dsmith-work>disassemble /r
<justin_smith>out of context, "set arm force-mode thumb" is funny
<RhodiumToad>weird.
<RhodiumToad>so it was showing it as thumb-mode code before
<RhodiumToad>and it obviously is, because in arm mode it's garbage
<dsmith-work>The jit builds thumb code.
<RhodiumToad>cpsr bit 5 is 1, so I guess we are in fact in thumb mode.
<dsmith-work>That bug monster arm-jit patch handled all the arm->thumb and thumb->arm jump. Including when jumping through a "veneer". (branch to a close by jump to far away code)
<RhodiumToad>so. the fact that it loads a constant 0 into r12 and then immediately uses it as a pointer does suggest bad code generation. but it's not clear why it doesn't happen predictably
<RhodiumToad>and why is it ldrt?
<dsmith-work>Yeah. A quick search says it's for os calls or something.
<dsmith-work>Also, thumb has limited registers. (they are all still there, you only get 3 bits in the opcode to specify them instead of 4 bits in arm mode)
<dsmith-work>Is 12 a valid register in thumb?
<dsmith-work>Must be, or it wouldn't disassemble.
<dsmith-work>What's the actual opcodes for that "ldrt r5, [r12]"
<RhodiumToad>=> 0x22ba90a8: 5c f8 00 5e ldrt r5, [r12]
<RhodiumToad>wonder if gdb is decoding this correctly
<dsmith-work>Try starting by += 2 bytes from there.
<dsmith-work>Alsom little endian, so the opcode is 0x5e00 0xf85c ?
<RhodiumToad>little endian, yes
<dsmith-work>I need to get gnus working. The web interface for my old email is totally hozed.
<RhodiumToad>I think the 0xf85c is the first halfword and 0x5e00 the second.
<RhodiumToad>and the reference manual does say that decodes to ldrt r5,[r12]
<dsmith-work>Ok.
<RhodiumToad>#define jit_ldrt_strt_p() 0
<RhodiumToad>and there are lots of if (jit_ldrt_strt_p() && ...)
<RhodiumToad>seems very weird
<dsmith-work>Like some temp code to be filled in later?
<dsmith-work> if (jit_ldrt_strt_p() && i0 >= 0 && i0 <= 255)
<dsmith-work> T2_LDRSBI(_jit, r0, r1, i0);
<dsmith-work>So right now, code like that *NEVER* takes the branch.
<dsmith-work>wingo: Got any comments on that?
<dsmith-work>Could that be the torri12() function generating that?
<RhodiumToad>shouldn't be.
<RhodiumToad>I think the only way it should get that is T_LDRI
<RhodiumToad>oops
<RhodiumToad>T2_LDRI
<RhodiumToad>THUMB2_LDRI is 0xf8500c00 and THUMB2_U is 0x00000200, so OR those and get 0xf850 0e00
<RhodiumToad>then fill in register numbers 12 and 5 and immediate 0, and get 0xf85c 5e00
<dsmith-work>Yes
<RhodiumToad>from context, I think this is an ldi_i
<RhodiumToad>so something called ldi_i(_jit, 5, 0)
<dsmith-work>Same thing here https://issues.guix.gnu.org/issue/39208
<dsmith-work>Or is that what you are working from?
<RhodiumToad>no, different place here and not reproducible
<dsmith-work>This looks similar:
<dsmith-work> 0xf5c43c9e: str r5, [r0, #16]
<dsmith-work> 0xf5c43ca0: mov.w r12, #0
<dsmith-work>=> 0xf5c43ca4: ldrt r5, [r12]
<dsmith-work> 0xf5c43ca8: str r5, [r0, #8]
<RhodiumToad>yes, that's probably also an ldi_i
<RhodiumToad>having it not be reproducible is a problem
<dsmith-work>Hmm. Maybe it's just because ldi_i() called trying to deref 0, and the real problem is somewhere else.
<RhodiumToad>ldi_i being called at all with a last parameter of 0 indicates a problem, I think
<RhodiumToad>if it were reproducible I would be setting a breakpoint for that
<dsmith-work>The segfaults I see are usually some SCM being 0.
<dsmith-work>Like scm_is_string (x=0x0)
<dsmith-work>That brings me back to something is overwriting something somewhere.
<RhodiumToad>are you building with or without threads?
<dsmith-work>The default ./configure, so with.
<dsmith-work>RhodiumToad: Good idea
<dsmith-work>RhodiumToad: There are couple of <<32 in hash.c that causes warnings in my compiler.
<RhodiumToad>yeah. but I think those are harmless because they're under conditionals that are false when the value being shifted is 32 bits.
<RhodiumToad>bad style, but probably not actual bugs
***_ is now known as Guest57951
<dsmith-work>Does this memset look like a noop?
<dsmith-work> pool->size = 0;
<dsmith-work> memset(pool->entries, 0, sizeof(pool->entries[0]) * pool->size);
<dsmith-work>In reset_literal_pool() in lightening.c
<dsmith-work>Should that be pool->capacity instead?
<RhodiumToad>hm, that does look odd
<dsmith-work>The alloc_* just below allocates capacity entries.
<RhodiumToad>question is whether anything cares about the content beyond pool->size
<dsmith-work>However, this is common code to all arches.
<dsmith-work>On the other hand, it is within #ifdef JIT_NEEDS_LITERAL_POOL, which is only for arm and aarch64
<RhodiumToad>I don't see anything that accesses beyond pool->size so I think it's harmless
<RhodiumToad>bicbw
<dsmith-work>Another thing I'm suspicious of is the constants in literal_pool_byte_size
<dsmith-work>Harmless but also useless.
<dsmith-work>Seems there was an intent to clear the thing.
<dsmith-work>So. configured --without-threads.
<dsmith-work>make check had one failure. Not sure where just yet
<dsmith-work>All the standalone tests passed.
<dsmith-work>FAIL: popen.test: open-output-pipe: no duplicate
<dsmith-work>
<dsmith-work>With threshold=0 got one standalone fail. FAIL: test-use-srfi
<dsmith-work>Second run ran all standalone checks
<dsmith-work>And again the popen test fails. But that might be due to no threads.
<dsmith-work>Nope. Still getting some failures.
<dsmith-work>Changed that memset to use capacity instead.
<dsmith-work>No failures so far.
<dsmith-work>sneek: later ask wingo: So is there any advantage to calling scm_gc_free() in jit_free_fn() ?
<sneek>Got it.
<dsmith-work>Nope. Still segfaults. (kind of expected it would)
<mauritslamers>@chrislck: https://gist.github.com/mauritslamers/65b0c8f59e48ba848d71fce8750de8c3
<mauritslamers>To me it feels like this could be done differently, but I don't know really how. Problem is mainly all the state variables that I need to keep around, and that define what needs to happen next.
<RhodiumToad>dsmith-work: I'm running standalone text without threads, and no failure yet after 10 runs
<dsmith-work>Is GUILE_JIT_THRESHOLD=0 ?
<RhodiumToad>y
<dsmith-work>Sounds good.
<dsmith-work>Note that I've had it fail after 12.
<dsmith-work>It it runs for 50 or so it's probably fixed
<RhodiumToad>except I didn't fix anything :-(
<dsmith-work>heh
<roelj>Is there a convenient way to see what is using how much memory in a Guile program?
<dsmith-work>RhodiumToad: I can eventually get a core dump from this:
<dsmith-work>while GUILE_JIT_THRESHOLD=0 ./meta/guile < /dev/null; do : ; done
<justin_smith>roelj: having done such profiling in other lisps, even when it's possible there's a gotcha that you can use "cons" in ways that lead to the same spine being used in many places, as the tail of multiple lists
<justin_smith>so even when you have a global view of all allocated memory, making sense of it requires application analysis
<RhodiumToad>dsmith-work: is this on a platform with ASLR? if so, have you tried disabling it?
<dsmith-work>RhodiumToad: What is ASLR ?
<RhodiumToad>address space layout randomization
<roelj>justin_smith: Well, I'd like to see what it looks like.. :)
<dsmith-work>Ah
<civodul>roelj: there's no heap profiler, unfortunately, but there's gcprof in (statprof)
<civodul>that shows you which parts of your code spend the most time allocating memory
<civodul>which is not exactly what you want, but can already be useful
<roelj>civodul: Thanks! It's going to be interesting to read anyway
<dsmith-work>RhodiumToad: Prob was enabled. Trying with it disabled.
<dsmith-work>RhodiumToad: That seems to have allowed guile < /dev/null to no longer segfault.
<RhodiumToad>interesting.
<RhodiumToad>what about other tests?
<dsmith-work>Running them now
<dsmith-work>Nope. Got a segfault.
<dsmith-work>Running 00-initial-env.test
<dsmith-work>Same story. Corrupt stack.
<dsmith-work>#1 0x76f556c0 in scm_i_string_ref (str=<optimized out>, x=478720) at strings.c:668
<dsmith-work>that x looks really wonky
<RhodiumToad>is it reproducible now, or still random?
<dsmith-work>make check failed at the same place.
<dsmith-work>I didn't save the core.
<dsmith-work>Yep
<dsmith-work>Identical backtraces
<dsmith-work>Well that's nice.
<dsmith-work>So.
<dsmith-work>What kind of bug would be address space dependant?
<dsmith-work>That probably includes mmap'ed memory allocation?
<dsmith-work>Why should the code care?
<dsmith-work>Unless it's acting on something uninitallized?
<dsmith-work>Of course, running that single test by hand has no failure.
<dsmith-work>civodul: Wasn't there some problem with some arch that needed some extra stack space?
<dsmith-work>Maybe it was windows?
<RhodiumToad>windows has a stack size set at link time and doesn't behave very nicely if you exceed it
<RhodiumToad>that's not the problem here
<dsmith-work>The thing I was thinking was like some reserved padding, before or after the stack.
<RhodiumToad>this is weird, I turned on some address randomization options on freebsd and tried the </dev/null test
<RhodiumToad>ooh, and I got some segfaults
<dsmith-work>Oi!
<RhodiumToad>#0 0x21cd4048 in scm_i_is_narrow_string (str=<optimized out>) at strings.c:548
<dsmith-work>Useful bt ?
<RhodiumToad>valid backtrace up to scm_i_str2symbol, which seems to have been called from jitted code and the stack isn't readable from there
<RhodiumToad>I think there's no way to get a valid backtrace through jitted code, because it's not conforming to the conventions that allow tracing
<dsmith-work>Hmm.
<dsmith-work>freebsd on arm?
<RhodiumToad>the option I turned on doesn't actually randomize the program load address, it only makes mmap() calls more random in the addresses they choose
<RhodiumToad>(might affect where shared libs get loaded I guess)
<RhodiumToad>freebsd 12-stable (not very recent, few months maybe), armv7 (compiled for cortex-A7), rpi2b
<RhodiumToad>ldr r0, [r0] and r0 = 0x0
<dsmith-work>Maybe the stack isn't being overwritten. Maybe some return code is popping the wrong values and loading a stack that's just something else entirely.
<dsmith-work>setting threshold to 0 seems to enhance the effect
<dsmith-work>Ah
<dsmith-work>wingo had a suggestion. There is a var that stops jitting after a count. Need to bisect the count.
<dsmith-work>I currently don't have an always fails single test
<dsmith-work>GUILE_JIT_STOP_AFTER