OK, so you want to test the Mastodon implementation for Bitlbee like I do after a long break?
Mastodon implementation for Bitlbee
Well, let’s say you did a `./configure --debug=1 --asan=1 --msn=0 --jabber=0 --oscar=0 --twitter=0 && make` in your directory and stuff crashes immediately. You want to debug. How does that work on macOS?
You try using gdb, and use the `BITLBEE_DEBUG` environment variable to have HTTP headers printed as you go:
alex@Megabombus:~/src/bitlbee (kensanata/develop %=)$ BITLBEE_DEBUG=1 gdb --args ~/src/bitlbee/bitlbee -D -n -F -v -d /Users/alex/.bitlbee -c /Users/alex/.bitlbee/bitlbee.conf GNU gdb (GDB) 8.0.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-apple-darwin16.7.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /Users/alex/src/bitlbee/bitlbee...done. .gdbinit:1: Error in sourced command file: Disabling randomization of debuggee's virtual address space is unsupported on this platform. (gdb) run Starting program: /Users/alex/Source/bitlbee/bitlbee Unable to find Mach task port for process-id 43768: (os/kern) failure (0x5). (please check gdb is codesigned - see taskgated(8))
OK, so the randomisation error is due to a line in `.gdbinit` and you can ignore it. You may also delete the file.
If you have used plugins such as `bitlbee-facebook` or `bitlbee-discord`, now would be a good time to delete them from `/usr/local/lib/bitlbee` until your issues are resolved.
You can’t ignore the part about codesigning, though. Luckily, the answer is simple:
alex@Megabombus:~/src/bitlbee (kensanata/develop %=)$ ls -l /usr/local/bin/gdb lrwxr-xr-x 1 alex admin 27 Oct 22 09:46 /usr/local/bin/gdb -> ../Cellar/gdb/8.0.1/bin/gdb alex@Megabombus:~/src/bitlbee (kensanata/develop %=)$ codesign -fs gdb-cert /usr/local/bin/gdb alex@Megabombus:~/src/bitlbee (kensanata/develop %=)$ codesign -fs gdb-cert /usr/local/bin/../Cellar/gdb/8.0.1/bin/gdb /usr/local/bin/../Cellar/gdb/8.0.1/bin/gdb: replacing existing signature
You will have to provide your username and password, twice.
Now, when you issue the `run` command, you will have to provide your username and password, again, but now it works:
(gdb) run Starting program: Starting program: /Users/alex/Source/bitlbee/bitlbee -D -n -F -v -d /Users/alex/.bitlbee -c /Users/alex/.bitlbee/bitlbee.conf [New Thread 0x1403 of process 43950] warning: unhandled dyld version (15) Warning: Warning: Couldn't write PID to `/var/run/bitlbee.pid'
You should now be able to connect to your local server (in my case, `megabombus.local`) using an IRC client.
And you’ll probably get an error like the following:
ASAN:DEADLYSIGNAL
=================================================================
==48642==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000b8f0 (pc 0x0001000ccf00 bp 0x7fff5fbfdaf0 sp 0x7fff5fbfda50 T0)
==48642==The signal is caused by a READ memory access.
#0 0x1000cceff in mastodon_http_timeline (bitlbee:x86_64+0x1000cceff)
#1 0x1000c2fc9 in mastodon_http_hashtag_timeline (bitlbee:x86_64+0x1000c2fc9)
#2 0x100078b80 in http_incoming_data (bitlbee:x86_64+0x100078b80)
#3 0x100074587 in gaim_io_invoke (bitlbee:x86_64+0x100074587)
#4 0x100251e63 in g_main_context_dispatch (libglib-2.0.0.dylib:x86_64+0x2ce63)
#5 0x100252161 in g_main_context_iterate (libglib-2.0.0.dylib:x86_64+0x2d161)
#6 0x1002523b6 in g_main_loop_run (libglib-2.0.0.dylib:x86_64+0x2d3b6)
#7 0x1000742af in b_main_run (bitlbee:x86_64+0x1000742af)
#8 0x100069e7f in main unix.c:182
#9 0x7fffe946e234 in start (libdyld.dylib:x86_64+0x5234)
And now you know where to look. Well, more or less. You need to convert that address to a line number:
(gdb) info line *0x1000cceff Line 1054 of "mastodon_lib.c" starts at address 0x1000ccebc <mastodon_http_timeline+28> and ends at 0x1000ccf07 <mastodon_http_timeline+103>.
Strangely enough, setting a breakpoint does not help. Hit `C-c` to break, `b mastodon_http_timeline` to set a breakpoint, `c` to continue, and try again – and you run into the same error without reaching a GDB prompt. This also happens if you run without ASAN. I’m not sure what the problem is, but in this situation you’re basically back to print statements and the like. Uagh!
☯
Oh, and Mastodon 2.0 changed all their ids from integers to string in their API and so everything is broken.
#Bitlbee #Mastodon #C
(Please contact me if you want to remove your comment.)
⁂
Also, I’m working on my branch, `kensanata/develop`. I have the remote `upstream` configured. So when I’m done and I have committed, I fetch from upstream, rebase onto `upstream/develop`, and force push that.
Later, when I’m ready to upgrade my Pull Request, I switch to my `master` branch. And then what? To be answered. 😄
– Alex 2017-10-23 05:17 UTC
---
Looks like my PR is not going to get merged. It’s a big chunk of code and tricky to review thoroughly, unfortunately. 🙁
– Alex 2017-10-23 14:53 UTC
---
Then again, based on the example of bitlbee-discord it was easy to turn my code into a plugin: bitlbee-mastodon!
– Alex 2017-10-24 06:55 UTC