Quote from vitaly_m :

No need for debuginfos really.., but you forgot to type 'bt' command right after the crash, and then there will be full backtrace.

Ow - sorry

Now you will find the backtrace in the log file attached.

Quote from Pasci :

Ow - sorry

Now you will find the backtrace in the log file attached.

This is gonna be fixed tommorow hopefully. Big thanks for the trace

Quote :

This is gonna be fixed tommorow hopefully. Big thanks for the trace

Sounds great - thank you for the fast fix

Quote from Pasci :

Sounds great - thank you for the fast fix

Unfortunately, I couldn't figure it out yet

It seems like we are getting damaged data from the network, or there is memory corruption inside the LFSTop itself...

I can try to figure it out if you generate core file...

So, instead of 'bt' you type 'generate-core-file', like this:


For now I will try to think about some package sanity checking and will make it ignore suspicious packets.

EDIT: Also, it would be useful to have debug_insim_packets true in srv1.ini

EDIT2: I wonder how do you reproduce this, would be easier for me to spot this.

Quote from vitaly_m :


(gdb) r
LFSTop starts... then crashes
(gdb) generate-core-file
Saved corefile core.7336


After you do this, do not post this file to public if you don't want admin password and other data to be studied by others. Write me PM, whenever you have something.

Does not work!

...
16.01.2017 19:47:07.851 INFO database saved: /data/lfstop/databases/RO11.dat
120 /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/ext/new_allocator.h: No such file or directory.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf6affb40 (LWP 17590)]
0x08237626 in __gnu_cxx::new_allocator<unsigned int>::construct<unsigned int, unsigned int const&> (this=0xf6afebe8, __p=0xf6113200)
at /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/ext/new_allocator.h:120
Missing separate debuginfos, use: zypper install libgcc_s1-32bit-debuginfo-4.8.3+r212056-2.4.4.x86_64 libstdc++6-32bit-debuginfo-4.8.3+r212056-2.4.4.x86_64 libz1-32bit-debuginfo-1.2.8-5.8.1.x86_64
(gdb) generate-core-file
Couldn't get registers: No such process.
(gdb) generate-core-file

Quote from Pasci :

Does not work!

...
16.01.2017 19:47:07.851 INFO database saved: /data/lfstop/databases/RO11.dat
120 /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/ext/new_allocator.h: No such file or directory.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf6affb40 (LWP 17590)]
0x08237626 in __gnu_cxx::new_allocator<unsigned int>::construct<unsigned int, unsigned int const&> (this=0xf6afebe8, __p=0xf6113200)
at /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/ext/new_allocator.h:120
Missing separate debuginfos, use: zypper install libgcc_s1-32bit-debuginfo-4.8.3+r212056-2.4.4.x86_64 libstdc++6-32bit-debuginfo-4.8.3+r212056-2.4.4.x86_64 libz1-32bit-debuginfo-1.2.8-5.8.1.x86_64
(gdb) generate-core-file
Couldn't get registers: No such process.
(gdb) generate-core-file

Try to run info threads before running generate-core-file. The bug we're getting is really strange for me, thanks for staying strong!

Version 2.0.6 released with important bug fixes:
Linux Windows

There is a development server running with a new !top window design, try it out: LFSTop Tracker Testing

Version 2.0.7 released with important bug fix for servers allowing bots:
Linux Windows

Well I think it might be the same problem that I had…
Sorry for this but every time it crash I have find nothing left including database.
And will it support Q10 or above？

Quote from kagurazakayukari :

Well I think it might be the same problem that I had…
Sorry for this but every time it crash I have find nothing left including database.
And will it support Q10 or above？

It should work with q10 already.

I need more info about your problem. What is the os? What kind of VM, if any? Is there any error message from OS? (On Linux you can try enabling core dumps to get more info or just run the app from inside gdb, on Windows there should be crash address reported somewhere) What do log files look like right after the crash?

For now I can only guess...

Is there a database file already on the disk?

Did it save database already before the crash and then failed to do that again?

Do you get empty database file after the crash?

If there is nothing you can tell, you can atleast drop me all the log files and databases files, so I try to investigate the problem myself...

Quote from vitaly_m :

It should work with q10 already.

I need more info about your problem. What is the os? What kind of VM, if any? Is there any error message from OS? (On Linux you can try enabling core dumps to get more info or just run the app from inside gdb, on Windows there should be crash address reported somewhere) What do log files look like right after the crash?

For now I can only guess...

Is there a database file already on the disk?

Did it save database already before the crash and then failed to do that again?

Do you get empty database file after the crash?

If there is nothing you can tell, you can atleast drop me all the log files and databases files, so I try to investigate the problem myself...

Will try at 0.6R ~
And I found another Chinese translation problem....have update

Do you plan any new features for LFS Top?

Quote from Pasci :

Do you plan any new features for LFS Top?

Not planning to do anything with that at all, sorry...

If there is any bug that I am able to fix, I will try to help, but otherwise I have pretty low interest in that.

Release candidate 2.0.8 released with some bug fixing, minor features and a move to 64bit


Linux Windows