Opened 8 weeks ago

Last modified 7 weeks ago

#32648 reopened defect

core dump centos8

Reported by: mikeb Owned by:
Priority: Medium Milestone: Tor: 0.4.2.x-final
Component: Core Tor/Tor Version: Tor: 0.4.1.6
Severity: Normal Keywords: centos core dump
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

CentOS 8 4.18.0-80.11.2.el8_0.x86_64.
Tor 0.4.1.6-1.el8.
Started with root and non-privileged user: /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc

torrc contains:

RunAsDaemon 1
BridgeRelay 1
ORPort 443
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:587
ExtORPort auto
ContactInfo test@…
ORPort 443
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:587
ExtORPort auto
ContactInfo test@…
Nickname mybridge

Child Tickets

Change History (6)

comment:1 Changed 8 weeks ago by mikeb

Core dump is 4MB so too large to attach.

Last edited 8 weeks ago by mikeb (previous) (diff)

comment:2 Changed 7 weeks ago by nickm

Milestone: Tor: 0.4.2.x-final

Can you use gdb with the core dump and the binary to generate a stack trace?

comment:3 Changed 7 weeks ago by mikeb

Silly me, it was the low port used for obfs4.

(gdb) bt
#0  0x00007f97bb67d93f in raise () from /lib64/libc.so.6
#1  0x00007f97bb667c95 in abort () from /lib64/libc.so.6
#2  0x000055812b25e4df in tor_abort_ () at src/lib/log/util_bug.c:173
#3  0x000055812b2d8109 in managed_proxy_stdout_callback (process=process@entry=0x55812ba27010, line=<optimized out>,
    line@entry=0x55812c307760 "SMETHOD-ERROR obfs4 listen tcp 0.0.0.0:587: bind: permission denied", size=<optimized out>) at src/feature/client/transports.c:1836
#4  0x000055812b3e9d63 in process_read_lines (callback=0x55812b2d7e60 <managed_proxy_stdout_callback>, buffer=0x55812ba430c0, process=0x55812ba27010) at src/lib/process/process.c:784
#5  process_read_data (process=0x55812ba27010, buffer=0x55812ba430c0, callback=0x55812b2d7e60 <managed_proxy_stdout_callback>) at src/lib/process/process.c:706

#6  0x00007f97bd171ff1 in event_process_active_single_queue () from /lib64/libevent-2.1.so.6
#7  0x00007f97bd172787 in event_base_loop () from /lib64/libevent-2.1.so.6
#8  0x000055812b3ae70b in tor_libevent_run_event_loop (base=<optimized out>, once=<optimized out>) at src/lib/evloop/compat_libevent.c:506
#9  0x000055812b273f03 in run_main_loop_once () at src/core/mainloop/mainloop.c:2423
#10 run_main_loop_until_done () at src/core/mainloop/mainloop.c:2489
#11 do_main_loop () at src/core/mainloop/mainloop.c:2380
#12 0x000055812b2602ae in run_tor_main_loop () at src/app/main/main.c:1235
#13 0x000055812b2615f5 in tor_run_main (tor_cfg=<optimized out>) at src/app/main/main.c:1330
#14 0x000055812b25eabe in tor_main (argc=7, argv=0x7fff7e32f988) at src/feature/api/tor_api.c:164
#15 0x000055812b25e64d in main (argc=<optimized out>, argv=<optimized out>) at src/app/main/tor_main.c:32

comment:4 Changed 7 weeks ago by gaba

Resolution: not a bug
Status: newclosed

We can close the ticket, right?

comment:5 Changed 7 weeks ago by mikeb

If you're happy with a core dump in this situation, go for it!

comment:6 Changed 7 weeks ago by nickm

Resolution: not a bug
Status: closedreopened

Well, we shouldn't take a crash in this case; we should exit with a reasonable message.

That said, I seem to recall that we did some work in this case for #31091, #31810, and so on, which are fixed in 0.4.2.x. Does the latest 0.4.2.x release (0.4.2.4-rc) still have this bug?

Note: See TracTickets for help on using tickets.