Well, I eventually got it to hang beating on it with 16 wget loops on the status page overnight. Although I’m not sure it’s not gdb that puked. Here’s what I ended up with from running it overnight:
page: aspl-license.html, uri: /status.html
Got directive session-count
Thread 3381875: Entering ws_dispatcher (Connection from 192.168.0.20)
Thread 3381872: included successfully
Got directive THREADSTAT
Got directive SERVICE-STATUS
Status inquiry
Received a message from daap server
Status inquiry — returning 0
Returning status 0
Executing: SELECT COUNT(*) FROM songs
[New Thread 2064079200 (LWP 2978)]
Couldn’t write floating point status: No such process.
^C eventually dropped me back to a gdb prompt, but gdb appears unresponsive
top shows:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14854 root 34 19 1307m 447m 600 R 5.7 45.2 164:54.94 gdb
Yes that’s 1.27GB VIRT :/
All in all of ~2GB physical mem + swap 8MB is free LOL
Would that be a leak in mt-daapd or gdb, or not a leak at all?
I’ll try running outside of gdb and see what pops up.