vysheng
tgl_peer_get returns NULL
Sometimes, shortly after launch, usually when someone messages the current user, calling tgl_peer_get() on M.to_id returns NULL.
Trying to get either a solution or better fail conditions.
After I get the tgl_message object, I can confirm the peer tree is empty, should this be possible?
(gdb) p TLS->peer_tree->left
$2 = (struct tree_peer *) 0x0
(gdb) p TLS->peer_tree->right
$3 = (struct tree_peer *) 0x0
Backtrace:
(gdb) bt
#0 0x00007ffff6132cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff61360d8 in __GI_abort () at abort.c:89
#2 0x00007ffff612bb86 in __assert_fail_base (fmt=0x7ffff627c830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7659d8 "tgl_peer_get (TLS, msg->to_id)", file=file@entry=0x76599d "python-types.c",
line=line@entry=1419, function=function@entry=0x765a30 <__PRETTY_FUNCTION__.15264> "tgl_Msg_FromTglMsg") at assert.c:92
#3 0x00007ffff612bc32 in __GI___assert_fail (assertion=0x7659d8 "tgl_peer_get (TLS, msg->to_id)", file=0x76599d "python-types.c",
line=1419, function=0x765a30 <__PRETTY_FUNCTION__.15264> "tgl_Msg_FromTglMsg") at assert.c:101
#4 0x000000000048d53c in tgl_Msg_FromTglMsg (msg=0xdd66440) at python-types.c:1419
#5 0x0000000000485803 in get_message (M=0xdd66440) at python-tg.c:224
#6 0x0000000000485c3c in py_new_msg (M=0xdd66440) at python-tg.c:302
#7 0x0000000000476e7f in print_message_gw (TLSR=0xda74010, M=0xdd66440) at interface.c:2320
#8 0x00000000004b3de9 in fetch_comb_binlog_msg_update (TLS=0xda74010, DS_U=0xdb411e0) at tgl/binlog.c:821
#9 0x00000000004b4752 in replay_log_event (TLS=0xda74010) at tgl/binlog.c:948
#10 0x00000000004b4f60 in add_log_event (TLS=0xda74010, data=0xd4192a0 <__packet_buffer+64>, len=12) at tgl/binlog.c:1094
#11 0x00000000004b5ea5 in bl_do_msg_update (TLS=0xda74010, id=5113) at tgl/binlog.c:1365
#12 0x00000000004b9c96 in tglu_work_update_short_message_new (TLS=0xda74010, check_only=0, DS_U=0xdb633e0) at tgl/updates.c:531
#13 0x00000000004b9fbc in tglu_work_any_updates_new (TLS=0xda74010, check_only=0, DS_U=0xdb633e0) at tgl/updates.c:592
#14 0x00000000004ba0ba in tglu_work_any_updates (TLS=0xda74010) at tgl/updates.c:615
#15 0x0000000000490e07 in rpc_execute_answer (TLS=0xda74010, c=0xdae4e20, msg_id=6152996158077415425) at tgl/mtproto-client.c:961
#16 0x0000000000491b66 in process_rpc_message (TLS=0xda74010, c=0xdae4e20, enc=0x3f28320 <Response.19228>, len=104)
at tgl/mtproto-client.c:1131
#17 0x0000000000491eca in rpc_execute (TLS=0xda74010, c=0xdae4e20, op=-888971994, len=104) at tgl/mtproto-client.c:1186
#18 0x00000000004bc303 in try_rpc_read (c=0xdae4e20) at tgl/tgl-net.c:488
#19 0x00000000004bc520 in try_read (c=0xdae4e20) at tgl/tgl-net.c:534
#20 0x00000000004bb3fc in conn_try_read (fd=6, what=2, arg=0xdae4e20) at tgl/tgl-net.c:250
#21 0x00007ffff7ba3f24 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5
#22 0x000000000046a909 in net_loop () at loop.c:215
#23 0x000000000046ce0d in loop () at loop.c:754
#24 0x0000000000469328 in inner_main () at main.c:456
#25 0x000000000046a402 in main (argc=3, argv=0x7fffffffe848) at main.c:994
This seems to have done it, I have not encountered it and I've been doing a lot of bot restarts for testing new features and plugins.
Nevermind, just got it again, this time, when a msg was waiting on the server sent to a group, and when it connected it fired an event for the msg, but the "to" peer on the msg object was not in the peer_tree yet.