@RalfJ Would you mind helping me a little? Do I need to compile
rustc to debug it with GDB? Inside of GDB, what should I do?
I just installed it and tested it with my hello world program (the one and only)
So at least I won't have to bother you with MacOS permissions and certificates and stuff :D
yeah I can only tell you how it works on Linux :P
so I assume you have a command
rustc <arguments> that is the culprit
if you have been using cargo to reproduce so far you'll have to distill this to a
rustc command first
then I would do
gdb rustc, after which a prompt opens. in that prompt you do
run <rustc argument>, which starts rustc. then you wait until you think it is in the endless/looooong loop you want to capture.
then you do Ctrl-C, and do
bt to print the backtrace, and copy-paste that
Oh it's that simple? :D
well if you get a backtrace successfully doing that
it may not work :)
this works pretty reliably for me...
okay if rustc does work off the main thread you might have to
thread apply all bt and find the right backtrace
(the exact command for this might be slightly different)
I got a
[New Thread 0xe03 of process 1445] message
So I guess it started in another thread?
yeah thats just gdb telling you a thread started, but it should go on after that
Let's let it run for 5 minutes or so
wow you are patient^^
so in the bug report, did it stop producing LOG output at some point?
I think it did
how long did that take?
But I think it was only set to debug
Let me find that out
probably best thing is to run gdb with the
RUSTC_LOG env var and then wait until the output stops
Hmm, doing Ctrl+C doesn't seem to work
Ctrl-C should get you to the gdb prompt
quit quits gdb
But it doesn't :eyes:
well that's... weird
I blame macOS :P
That's worrying :D
no idea if that makes any sense
does "command + ." do anything?^^
Doesn't seem like it
Well MacOS is just another UNIX system
some other places of the internet suggest using lldb instead
I never used that but I presume it is mostly compatible with gdb...
Oh wow, Ctrl-Z got me:
 + 1440 suspended gdb rustc src/main.rs
But no gdb prompt though :P
yah Ctrl-Z would send the entire thing to the background
but now you can
kill %1 :D
I mean I can also close my terminal
But that won't help
right but that above kills the first background process
@RalfJ I've heard reports that on some platforms gdb is .. less than ideal, and sometimes just doesn't give backtraces
Let's try with lldb then I guess
RUSTC_LOG so you can see when the log stops moving
Yeah I don’t recommend gdb on macOS, you’re going to run into a bunch of problems. I still haven’t figured out how to correctly enable it without permanently disabling system integrity protection. All the guides are out of date or wrong.
(lldb) target create rustc Current executable set to 'rustc' (x86_64). (lldb) run +nightly src/main.rs Process 1712 launched: '/Users/tous/.cargo/bin/rustc' (x86_64) Process 1712 stopped * thread #2, stop reason = exec frame #0: 0x000000010026a000 dyld`_dyld_start dyld`_dyld_start: -> 0x10026a000 <+0>: popq %rdi 0x10026a001 <+1>: pushq $0x0 0x10026a003 <+3>: movq %rsp, %rbp 0x10026a006 <+6>: andq $-0x10, %rsp Target 0: (rustc) stopped.
oh... we probably need to move one wrapper down
rustc here is still the
So I want to use the path to the binary?
the actual rustc binary is somewhere in...
so you want to use
lldb ~/.rustup/toolchains/nightly/... or so
Yeah, it works
And already stopped at
LEAVING(0) main (unwinding = false)
Here's what I get:
(lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fff6ce289f6 libsystem_kernel.dylib`__ulock_wait + 10 frame #1: 0x00007fff6ceef385 libsystem_pthread.dylib`_pthread_join + 323 frame #2: 0x0000000106eebe90 libstd-0f45f03d2da49250.dylib`std::sys::unix::thread::Thread::join::he4b5475ec86f3950 + 16 frame #3: 0x000000010048f8f6 librustc_driver-e74b82e42afdd3af.dylib`std::thread::JoinHandle$LT$T$GT$::join::hb00ce852782dd91f + 54 frame #4: 0x00000001004d4899 librustc_driver-e74b82e42afdd3af.dylib`rustc_interface::util::spawn_thread_pool::h5019077c47c5b3d4 + 537 frame #5: 0x00000001004b83df librustc_driver-e74b82e42afdd3af.dylib`rustc_driver::run_compiler::hec7ed5e1b2ad17c0 + 7663 frame #6: 0x00000001004f9b48 librustc_driver-e74b82e42afdd3af.dylib`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::hc5599978260bb5a2 + 120 frame #7: 0x00000001004be432 librustc_driver-e74b82e42afdd3af.dylib`rustc_driver::catch_with_exit_code::h8593be9703207610 + 18 frame #8: 0x00000001004bf58b librustc_driver-e74b82e42afdd3af.dylib`rustc_driver::main::hddcc79ad40e9575f + 43 frame #9: 0x0000000100000cde rustc`rustc_binary::main::heca050561af94105 + 14 frame #10: 0x0000000100000d16 rustc`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h3c5158dd276dd7dc + 6 frame #11: 0x0000000106eddc69 libstd-0f45f03d2da49250.dylib`std::rt::lang_start_internal::heec5cb3c6d314455 + 441 frame #12: 0x0000000100000d09 rustc`main + 41 frame #13: 0x0000000100000cc4 rustc`start + 52
I guess I need to navigate through the threads, right?
yeah thats the main thread
and its not helpful
also ugh why doesn't it resolve the symbols :/
How would you proceed on GDB?
thread apply all bt
LLDB seems very similar
then you get the backtraces of all threads
(I should also note that we are going through more than 80% of my gdb knowledge here. I am not a gdb guru, I just know how to do this one thing.^^)
Doesn't work on lldb unfortunately
(lldb) thread list Process 1738 stopped * thread #1: tid = 0x5179, 0x00007fff6ce289f6 libsystem_kernel.dylib`__ulock_wait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP thread #2: tid = 0x5194, 0x0000000102f320d4 librustc_driver-e74b82e42afdd3af.dylib`_$LT$rustc_mir..interpret..intern..InternVisitor$LT$M$GT$$u20$as$u20$rustc_mir..interpret..visitor..ValueVisitor$LT$M$GT$$GT$::visit_value::h37ced94f75053e5e + 1236, name = 'rustc' ````
Any useful info in there?
Thread 2 seems suspicious :D
looks like the lldb thing is
Yeah that works
Raw output is too large for Zulip though :laughing:
just put it in the GH issue (in
<details> like you did with the log)
I need to get to sleep anyway ;)
gist, please, though
I need to get to sleep anyway ;)
Thanks a whole lot for the help
gist, please, though
any reason to prefer that over the foldable
@LeSeulArtichaut thank you for looking into this issue :)
<details> won't fold in ~all email clients I'm aware of
so you end up with a very long email
not to mention that it's a pain to scroll in github's ui, I'd much rather firefox's plain text view or w/e
Created a gist
Last frame is:
frame #0: 0x0000000102f320d4 librustc_driver-e74b82e42afdd3af.dylib`_$LT$rustc_mir..interpret..intern..InternVisitor$LT$M$GT$$u20$as$u20$rustc_mir..interpret..visitor..ValueVisitor$LT$M$GT$$GT$::visit_value::h37ced94f75053e5e + 1236
So I think this is definitely a const-eval problem?
@LeSeulArtichaut btw, this is a nice thing to better document on Rustc Dev Guide :)
I was also thinking that :D
I had the idea of gathering a bunch of chapters we have an create a complete introspection section
plus some new content probably
<details>won't fold in ~all email clients I'm aware of
it folds in thunderbird, FWIW, so I wasnt aware.^^