@mfikes: just pushed a fix to: https://github.com/johanatan/planck/commit/788abbebb55420ee46c90f9bf3b1974804702ace but unfortunately same problem results.

[just that printf'ing the buffer now produces expected results]

@mfikes: btw, which debugger are you using? I just tried using gdb but am getting some strange internal gdb error:

Temporary breakpoint 1, 0x0000000100039404 in main ()
(gdb) step
Single stepping until exit from function main,
which has no line number information.
[New Thread 0x12c7 of process 78632]
[New Thread 0x1403 of process 78632]
[New Thread 0x1503 of process 78632]
[New Thread 0x1603 of process 78632]
[New Thread 0x1703 of process 78632]
[New Thread 0x1803 of process 78632]
[New Thread 0x1903 of process 78632]
[New Thread 0x1a03 of process 78632]
[New Thread 0x1b1b of process 78632]
Planck 2.0
ClojureScript 1.9.89
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
    Exit: Control+D or :cljs/quit or exit or quit
 Results: Stored in vars *1, *2, *3, an exception in *e

cljs.user=> [New Thread 0x13eb of process 78632]
                                                [New Thread 0x1d03 of process 78632]
                                                                                    [New Thread 0x1e03 of process 78632]
                                                                                                                        [New Thread 0x1f03 of process 78632]
                      [New Thread 0x2003 of process 78632]
                                                          [New Thread 0x2103 of process 78632]
                                                                                              [New Thread 0x2203 of process 78632]
                                                                                                                                  [New Thread 0x2303 of process 78632]
                                infrun.c:5503: internal-error: int finish_step_over(struct execution_control_state *): Assertion `ecs->event_thread->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) 

Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

infrun.c:5503: internal-error: int finish_step_over(struct execution_control_state *): Assertion `ecs->event_thread->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) 

also, i doubt that gdb would end up being super useful anyway without sources and symbols setup for javascriptcore (which i'm not sure how to do)

@johanatan: I compiled with -g and then used lldb. I found that Linenoise appears to interfere, so after starting lldb planck, I do run -d to put Planck in dumb-terminal mode.

ok, and how do you get javascriptcore sources and symbols setup so you can actually see what the problem is (instead of random binary offsets and ASM instructions :))

this is the lldb output if you can make sense of it:

cljs.user=> (require '[planck.shell])
nil
cljs.user=> (planck.shell/sh-async "ls" :dir "/Users/jonathan/Documents" :env {"blah" "blaz"} (fn [_] 9))
{:exit nil, :out nil, :err nil}
cljs.user=> 
Process 79650 stopped
* thread #19: tid = 0x9a43f6, 0x00007fff8ee337e1 JavaScriptCore`WTF::String::isolatedCopy() const & + 17, stop reason = EXC_BAD_ACCESS (code=1, address=0x3100000011)
    frame #0: 0x00007fff8ee337e1 JavaScriptCore`WTF::String::isolatedCopy() const & + 17
JavaScriptCore`WTF::String::isolatedCopy:
->  0x7fff8ee337e1 <+17>: movl   0x10(%rax), %edx
    0x7fff8ee337e4 <+20>: movl   %edx, %ecx
    0x7fff8ee337e6 <+22>: andl   $0x8, %ecx
    0x7fff8ee337e9 <+25>: testb  $0x3, %dl
(lldb) 

If you type u you should move up a stack frame and d for down

I can’t recall, but perhaps bt shows a backtrace

ya, that doesn't give me any more info than the original stack trace i posted though.

i would really need to be able to see the line of source corresponding to: JavaScriptCoreWTF::String::isolatedCopy() const & + 17`

@mfikes: is there no way to hook up sources and symbols? I think trying to decipher this via disassembly is going to prove impossible

@johanatan: I don’t know. It might be the case that on Linux there are debug builds of JavaScripCore, and on OS X perhaps there is a way to run the C-based project by Xcode and attach symbols, etc. I haven’t gone down that path yet.

@mfikes: ok, i'll see what i can do with the disassembly and if that goes nowhere, then I'll explore the XCode option

@mfikes: I think actually the best thing to do here is to build webkit from sources in debug mode and then link our C-binary against the freshly built webkit bits. Then things will "just work" (i.e., lldb will know line numbers and full paths to source files from the embedded debug info in the webkit binaries).

@mfikes: after a lot of yak shaving, i got it building with a debug webkit

but on startup, I get:

Jonathans-MacBook-Pro:planck-c jonathan$ ./planck 
ASSERTION FAILED: s_mainRunLoop
/Users/jonathan/Documents/SourceCode/webkit/Source/WTF/wtf/RunLoop.cpp(66) : static WTF::RunLoop &WTF::RunLoop::main()
1   0x1109f3dbd WTFCrash
2   0x110a22dfb WTF::RunLoop::main()
3   0x11041166b Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask(Inspector::HeapFrontendDispatcher&)
4   0x11041186d Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask(Inspector::HeapFrontendDispatcher&)
5   0x110411cb4 Inspector::InspectorHeapAgent::InspectorHeapAgent(Inspector::AgentContext&)
6   0x110411d7d Inspector::InspectorHeapAgent::InspectorHeapAgent(Inspector::AgentContext&)
7   0x11054c9a5 Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController(JSC::JSGlobalObject&)
8   0x11054eebd Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController(JSC::JSGlobalObject&)
9   0x11050c215 JSC::JSGlobalObject::init(JSC::VM&)
10  0x1104f3fa0 JSC::JSGlobalObject::finishCreation(JSC::VM&)
11  0x1104f359c JSC::JSGlobalObject::create(JSC::VM&, JSC::Structure*)
12  0x1104f2696 JSGlobalContextCreateInGroup
13  0x1104f2571 JSGlobalContextCreate
14  0x10f90bf1b main
15  0x7fff95e555ad start
ASAN:DEADLYSIGNAL
=================================================================
==55205==ERROR: AddressSanitizer: SEGV on unknown address 0x0000bbadbeef (pc 0x0001109f3dc4 bp 0x7fff5032a100 sp 0x7fff5032a100 T0)
    #0 0x1109f3dc3 in WTFCrash (planck+0x101123dc3)
    #1 0x110a22dfa in WTF::RunLoop::main() (planck+0x101152dfa)
    #2 0x11041166a in Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask(Inspector::HeapFrontendDispatcher&) (planck+0x100b4166a)
    #3 0x11041186c in Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask(Inspector::HeapFrontendDispatcher&) (planck+0x100b4186c)
    #4 0x110411cb3 in Inspector::InspectorHeapAgent::InspectorHeapAgent(Inspector::AgentContext&) (planck+0x100b41cb3)
    #5 0x110411d7c in Inspector::InspectorHeapAgent::InspectorHeapAgent(Inspector::AgentContext&) (planck+0x100b41d7c)
    #6 0x11054c9a4 in Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController(JSC::JSGlobalObject&) (planck+0x100c7c9a4)
    #7 0x11054eebc in Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController(JSC::JSGlobalObject&) (planck+0x100c7eebc)
    #8 0x11050c214 in JSC::JSGlobalObject::init(JSC::VM&) (planck+0x100c3c214)
    #9 0x1104f3f9f in JSC::JSGlobalObject::finishCreation(JSC::VM&) (planck+0x100c23f9f)
    #10 0x1104f359b in JSC::JSGlobalObject::create(JSC::VM&, JSC::Structure*) (planck+0x100c2359b)
    #11 0x1104f2695 in JSGlobalContextCreateInGroup (planck+0x100c22695)
    #12 0x1104f2570 in JSGlobalContextCreate (planck+0x100c22570)
    #13 0x10f90bf1a in main main.c:268
    #14 0x7fff95e555ac in start (libdyld.dylib+0x35ac)
    #15 0x0  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (planck+0x101123dc3) in WTFCrash
==55205==ABORTING
Abort trap: 6

Cool. Symbols 🙂

Ya, it was pretty tricky with lots of trial and error but I can describe the process that finally worked

basically: a) build webkit in debug mode (i.e., clone the sources and issue make debug) b) merge the object files for bmalloc, JavaScriptCore & WTF into single .o files using libtool. c) modify makefile to link directly to aforementioned .o files and change LIBFLAGS to LIBFLAGS += -framework AppKit $(shell pkg-config --libs $(DEPS)) -licucore

i'm guessing that the crash above is a missing dependency (but all of those previously either caused the make to build (at compile time) or a runtime linker error like the following:

Jonathans-MacBook-Pro:planck-c jonathan$ ./planck 
dyld: Symbol not found: _OBJC_CLASS_$_EventSendingController
  Referenced from: libwebkit.dylib
  Expected in: flat namespace
 in libwebkit.dylib
Trace/BPT trap: 5

@johanatan: I think JavaScriptCore can be built with and without Objective-C support. Perhaps that’s what you are seeing.

ahh, yep.

i bet so

I will look into flags to pass to webkit's make to disable obj-c