Project

General

Profile

Bug #722

SIGABRT using lttng-relayd (assertion failed)

Added by Marc-Andre Laperle about 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Target version:
Start date:
01/20/2014
Due date:
% Done:

100%

Estimated time:

Description

I am using lttng-tools-2.4.0 rc3.
I am not sure how to reproduce this yet but I was connecting to lttng-relayd and testing things out (attaching to a session, etc). I'll try to narrow it down a bit.

Core was generated by `lttng-relayd -d'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f1f86c0bf39 in GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0 0x00007f1f86c0bf39 in _GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 2144
selftid = 2148
#1 0x00007f1f86c0f348 in __GI_abort () at abort.c:89
save_stage = 2
act = {
_sigaction_handler = {sa_handler = 0x7fff052612f0, sa_sigaction = 0x7fff052612f0}, sa_mask = {__val = {
139773382834504, 139773391825742, 143, 4294967295, 139773381470035, 0, 139773364476288, 73014444032, 0, 0, 0, 0, 0,
21474836480, 139773396193280, 139773382849760}}, sa_flags = -2023856016,
sa_restorer = 0x7f1f875e6f60 <__PRETTY_FUNCTION
.6006>}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007f1f86c04df6 in assert_fail_base (fmt=0x7f1f86d574e0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7f1f875e6870 "!ret", file=file@entry=0x7f1f875e6b4e "hashtable.c", line=line@entry=143,
function=function@entry=0x7f1f875e6f60 <__PRETTY_FUNCTION
.6006> "lttng_ht_destroy") at assert.c:92
str = 0x7f1f70001c30 ""
total = 4096
#3 0x00007f1f86c04ea2 in GIassert_fail (assertion=assertion@entry=0x7f1f875e6870 "!ret",
file=file@entry=0x7f1f875e6b4e "hashtable.c", line=line@entry=143,
function=function@entry=0x7f1f875e6f60 <
_PRETTY_FUNCTION__.6006> "lttng_ht_destroy") at assert.c:101
No locals.
#4 0x00007f1f875d9f4a in lttng_ht_destroy (ht=0x7f1f70000d00) at hashtable.c:143
ret = <optimized out>
PRETTY_FUNCTION = "lttng_ht_destroy"
#5 0x00000000004084fd in relay_thread_worker (data=0x20220a0) at main.c:2641
ret = <optimized out>
err = 0
last_seen_data_fd = <optimized out>
nb_fd = <optimized out>
relay_connection = <optimized out>
events = {epfd = 17, nb_fd = 4, alloc_size = 4, init_size = 2, events = 0x7f1f70001630}
relay_connections_ht = <optimized out>
node = <optimized out>
iter = {iter = {node = 0x0, next = 0x0}}
recv_hdr = {circuit_id = 0, data_size = 1152921504606846976, cmd = 117440512, cmd_version = 0}

#1

Updated by David Goulet about 6 years ago

  • Status changed from New to Feedback

Same as #723 and #726

#2

Updated by Marc-Andre Laperle over 5 years ago

I got the same assertion by reproducing #853 using Lttng Tools 2.5.1.

#3

Updated by Christian Babeux over 5 years ago

  • Assignee set to Julien Desfossez
  • Target version set to 2.6
#4

Updated by Julien Desfossez over 5 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

Applied in changeset tools|commit:f233ab3013d240b84708464dd56d6656a480bd3e.

Also available in: Atom PDF