new redis bug report format on crash.

gistfile1.txt

[77046] 24 Nov 15:39:49 # === REDIS BUG REPORT START: Cut & paste starting from here ===
[77046] 24 Nov 15:39:49 #     Redis 2.9.0 crashed by signal: 11
[77046] 24 Nov 15:39:49 #     Failed assertion: <no assertion failed> (<no file>:0)
[77046] 24 Nov 15:39:49 # --- STACK TRACE
[77046] 24 Nov 15:39:49 # 1   redis-server                        0x00000001045d2e74 debugCommand + 68
[77046] 24 Nov 15:39:49 # 2   ???                                 0x00007fff641a8274 0x0 + 140734872846964
[77046] 24 Nov 15:39:49 # 3   redis-server                        0x00000001045af753 call + 67
[77046] 24 Nov 15:39:49 # 4   redis-server                        0x00000001045afc20 processCommand + 992
[77046] 24 Nov 15:39:49 # 5   redis-server                        0x00000001045b8a30 processInputBuffer + 160
[77046] 24 Nov 15:39:49 # 6   redis-server                        0x00000001045ab2ea aeProcessEvents + 634
[77046] 24 Nov 15:39:49 # 7   redis-server                        0x00000001045ab4fe aeMain + 62
[77046] 24 Nov 15:39:49 # 8   redis-server                        0x00000001045b110b main + 635
[77046] 24 Nov 15:39:49 # 9   redis-server                        0x00000001045aa4e4 start + 52
[77046] 24 Nov 15:39:49 # 10  ???                                 0x0000000000000001 0x0 + 1
[77046] 24 Nov 15:39:49 # --- INFO OUTPUT
[77046] 24 Nov 15:39:49 # # Server
redis_version:2.9.0
redis_git_sha1:45e7a1ce
redis_git_dirty:1
arch_bits:64
multiplexing_api:kqueue
process_id:77046
tcp_port:6379
uptime_in_seconds:1
uptime_in_days:0
lru_clock:93982

# Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

# Memory
used_memory:993440
used_memory_human:970.16K
used_memory_rss:1568768
used_memory_peak:942432
used_memory_peak_human:920.34K
used_memory_lua:22528
mem_fragmentation_ratio:1.58
mem_allocator:libc

# Persistence
loading:0
aof_enabled:0
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1322145588
bgrewriteaof_in_progress:0

# Stats
total_connections_received:1
total_commands_processed:0
rejected_connections:0
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0

# Replication
role:master
connected_slaves:0

# CPU
used_cpu_sys:0.00
used_cpu_user:0.01
used_cpu_sys_children:0.00
used_cpu_user_children:0.00

# Commandstats

# Cluster
cluster_enabled:0

# Keyspace

[77046] 24 Nov 15:39:49 # --- CLIENT LIST OUTPUT
[77046] 24 Nov 15:39:49 # addr=127.0.0.1:63909 fd=5 idle=0 flags=N db=0 sub=0 psub=0 qbuf=0 obl=0 oll=0 events=r cmd=debug

[77046] 24 Nov 15:39:49 # === REDIS BUG REPORT END. Make sure to include from START to END. ===

It might be useful to call gdb form signal handler, to get more details for stacktrace, given the user has gdb installed...
Something like: gdb -ex "thread apply all where full" -batch -p <my_pid>

How about google breakpad?

@ladenBrain: Yes... probably not a bad idea. What this could provide is additional line numbers in stack trace I guess. I'll do a few tests, thanks.

@AlekSi: Too much dependencies, and does not help us more than the stack trace. What does a real difference is the full dump... that allows us to inspect the status of the memory (not just thread stacks). Most of the interesting stuff in Redis, including the content of the arguments of a command, are allocated in the heap as Redis Objects.

Thank you both for the suggestions!

@antirez: function parameters and local variables are also very helpful. Unfortunately, source printout with -O2 is mostly useless...

@ladenBrain: yes but most of the times function parameters and local vars that matter in Redis are like: robj *foo, robj *bar, sds bla. Everything a pointer to a stack allocated thing.

If gdb isn't installed then addr2line (from binutils) is worth a try for getting basic information for a bug report.