debugging hls guidelines

[teto]

I've had haskell-language-server crashing all the time for the past month over all my multicradle projects. I've switched to using the flake (thanks for making that !) and I wonder if there are some guidelines somewhere as how to debug that. I had to incrase the coredump ExternalSizeMax to get a full coredump (system grinds to a halt) via (on nixos)::

  systemd.coredump.extraConfig = ''
    ProcessSizeMax=20G
    ExternalSizeMax=20G
    '';

after a crash I run coredumpctl debug but gdb doesn't manage to load the coredump, it stays stuck as in an infinite loop:

Type "apropos word" to search for commands related to "word"...
Reading symbols from /nix/store/6kdhg6jmzlil02npp383jmckvqfx6q8z-haskell-language-server-1.1.0.1/bin/haskell-language-server...
(No debugging symbols found in /nix/store/6kdhg6jmzlil02npp383jmckvqfx6q8z-haskell-language-server-1.1.0.1/bin/haskell-language-server)

warning: core file may not match specified executable file.

warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading symbols from /nix/store/v8q6nxyppy1myi3rxni2080bv8s9jxiy-glibc-2.32-40/lib/libpthread.so.0...
(No debugging symbols found in /nix/store/v8q6nxyppy1myi3rxni2080bv8s9jxiy-glibc-2.32-40/lib/libpthread.so.0)

and even if it could load it apparently the binary lacks synbols ? Would it be possible to provide a debug package in the flake ?

• add some instructions at https://github.com/haskell/haskell-language-server/blob/master/CONTRIBUTING.md

Steps to reproduce

Expected behaviour

Actual behaviour

Include debug information

Execute in the root of your project the command haskell-language-server --debug . and paste the logs here:

Debug output:

<paste your logs here>

Paste the logs from the lsp-client, e.g. for VS Code

LSP logs:

<paste your logs here>

[jneira]

Maybe any of the maintainers using nix could help us here: @berberman, @pepeiborra?

[teto]

I've created https://github.com/teto/haskell-language-server/tree/flake-debug and generated a coredump with it. After 50 minutes gdb 10.2 has not loaded the coredump yet (3GB uncompressed). I've attached a gdb to gdb (sic) and gets this kind of trace when interrupting the gdb loading the coredump

#0  0x00000000005c6a97 in section_table_xfer_memory_partial(unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*, target_section*, target_section*, gdb::function_view<bool (target_section const*)>) ()
#1  0x0000000000537736 in core_target::xfer_partial(target_object, char const*, unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*) ()
#2  0x00000000008509e1 in raw_memory_xfer_partial(target_ops*, unsigned char*, unsigned char const*, unsigned long, long, unsigned long*) ()
#3  0x0000000000850b45 in memory_xfer_partial_1(target_ops*, target_object, unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*) ()
#4  0x000000000085e3ca in target_xfer_partial(target_ops*, target_object, char const*, unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*) ()
#5  0x000000000085e8d1 in target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long) ()
#6  0x000000000085e94a in target_read_memory(unsigned long, unsigned char*, long) ()
#7  0x0000000000730ea5 in ps_xfer_memory(ps_prochandle const*, void*, unsigned char*, unsigned long, int) ()
#8  0x00007f03527ba093 in td_thr_get_info () from /nix/store/sbbifs2ykc05inws26203h0xwcadnf0l-glibc-2.32-46/lib/libthread_db.so.1
#9  0x0000000000670e90 in find_new_threads_callback(td_thrhandle const*, void*) ()
#10 0x00007f03527b9bdd in iterate_thread_list () from /nix/store/sbbifs2ykc05inws26203h0xwcadnf0l-glibc-2.32-46/lib/libthread_db.so.1
#11 0x0000000000670ca0 in find_new_threads_once(thread_db_info*, int, td_err_e*) ()
#12 0x0000000000670dea in thread_db_find_new_threads_2(thread_info*, bool) ()
#13 0x000000000067258f in try_thread_db_load(char const*, bool) ()
#14 0x00000000006732f8 in check_for_thread_db() ()
#15 0x000000000082a20a in symbol_file_add_with_addrs(bfd*, char const*, enum_flags<symfile_add_flag>, std::vector<other_sections, std::allocator<other_sections> >*, enum_flags<objfile_flag>, objfile*) ()
#16 0x00000000007fddf5 in solib_read_symbols(so_list*, enum_flags<symfile_add_flag>) ()
#17 0x00000000007ff02c in solib_add(char const*, int, int) ()
#18 0x000000000062c46c in post_create_inferior(target_ops*, int) ()
#19 0x0000000000537f08 in core_target_open(char const*, int) ()
#20 0x0000000000690043 in catch_command_errors(void (*)(char const*, int), char const*, int) ()
#21 0x0000000000691e82 in captured_main_1(captured_main_args*) ()
#22 0x000000000069236b in gdb_main(captured_main_args*) ()
#23 0x0000000000430dfc in main ()

I wonder if there is any specific hls-specific gdb config trick that could help/ if anyone has witnessed this already ?

[teto]

After talking on the gdb mailing list, it seems gdb is unable to load the backtrace because of a bug in gdb. If you want to reproduce, you can checkout https://github.com/teto/quantum/commit/ce8512ed70210230481dbca81feb263d8e80f30c , nix develop (most reproducible since everything is pinned), then haskell-language-server src it doesn't crash at the same place everytime but for instance

File:     /home/teto/mptcp/quantum/src/MptcpAnalyzer/Commands/List.hs
Hidden:   no
Range:    1:1-2:1
Source:   typecheck
Severity: DsWarning
Message:  Renamer/typechecker [MptcpAnalyzer.Commands.List]: alloc=926993552 time=2316.554
Segmentation fault (core dumped)

[michaelpj]

Closing as old and quiet