I experienced more core dumps, but haven't had time to examine them.
In particular, at a time I had three core dumps in a row on Jul 14:
-rw--- 1 ale staff 6180864 Jul 14 17:10
core_epoch=1531581032_pid=5409_file=!usr!sbin!famd
-rw--- 1 ale staff 9302016 Jul 14 17:09
core_epoch=1531580
On sat 26 may 2018 it segfaulted again. Identical pattern:
(gdb) bt
#0 0x6811 in ?? ()
#1 0x00412b1c in TCP_Client::unblock_handler (closure=0xdb1870) at
TCP_Client.c++:270
#2 0x004105dc in Scheduler::handle_io (fds=0xaf3eb0,
fds@entry=0x7ffc71013620,
iotype=&
On Fri, 30 Mar 2018 12:47:15 +0200 I wrote:
> That suggests that Set.h doesn't work as expected.
No, that wasn't the case. A couple of days ago I got a core dump with exactly
the same back trace (bt), even if using std::set.
Core was generated by `/usr/sbin/famd -v -f -T 0'.
Program terminated
Yesterday I got another core dump and, again, it was like the previous ones:
#1 0x00412927 in TCP_Client::unblock_handler (closure=0x1ffa030) at
TCP_Client.c++:270
I checked the assertions were indeed compiled in, by (gdb) disass
((TCP_Client*)$closure)->dequeue_from_scan, which ended
Yesterday it happened again, exactly the same pattern:
Reading symbols from ./build-tree/fam-2.7.0/src/famd...done.
[New LWP 18773]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/famd -v -f -
Package: fam
Version: 2.7.0-17.1
Followup-For: Bug #483811
I eventually managed to compile a non-stripped version of famd.
In order to run it, I modified /etc/init.d/fam, which reportbug
detected and automatically copied below (search "-ale:"). I'll
attach /root/famd-wrapper in a moment. It's a
Package: fam
Version: 2.7.0-13.2
Severity: normal
--- Please enter the report below this line. ---
no idea why, but i found this in my /var/log/messages:
kernel: famd[3044]: segfault at e08 rip 414f45 rsp 7fffedd01c80 error 4
sorry, I don't have anything more.
jürgen
--- System informatio
7 matches
Mail list logo
