Check if this problem is fixed:Ok, I already did this uptime of 2 hours and still has not fallen, I'm using OTX 2 BY ciroc.
sudo apt install gdb
ulimit -c unlimited
./otx
I did the above precedent but I can't find the log file after another core dump. where is it pleaseCheck if this problem is fixed:
C++ - Crash Party TFS 0.4 (8.60)
If you run it on linux, first install 'gdb' (debugger):
Then, set limit of crash report to disc size = unlimited (in most cases it will use 3-4GB on HDD):PHP:sudo apt install gdb
Then just run your server:PHP:ulimit -c unlimited
(or whatever you name your binary file)PHP:./otx
After next crash there should appear file named 'core' in folder with binary file. Then you can use it to detect problem.
I can try to help you, add me on Skype: [email protected]
If it's new ubuntu (20+), you got to disableI did the above precedent but I can't find the log file after another core dump. where is it please
apport
- application that handles crashes and deletes your core
file:sudo systemctl stop apport
sudo systemctl disable apport
i got it, ubuntu 22. but i think is ok right?:If it's new ubuntu (20+), you got to disableapport
- application that handles crashes and deletes yourcore
file:
Code:sudo systemctl stop apport sudo systemctl disable apport
if you're not running apport, it should save a core if it crashes again if you're using gdb.i got it, ubuntu 22. but i think is ok right?:
apport.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apport
It's fine. It means it was enabled and now it's disabled. It should now saveapport.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apport
core
file in folder where you run application.core
file by executing:cat /proc/sys/kernel/core_pattern
core
, it means it will save in folder where you run app.thanksss!!!It's fine. It means it was enabled and now it's disabled. It should now savecore
file in folder where you run application.
You can check where it will storecore
file by executing:
If it printsCode:cat /proc/sys/kernel/core_pattern
core
, it means it will save in folder where you run app.
shit.. I was looking at the console now, and this morning I had this problem, similar to coredump... yesterday I did another update, but I completely closed restart.sh and opened it again. What can it be?corrupted size vs. prev_size
./restart.sh: line 3: 73677 Aborted ./tfs
while true;
do ./tfs;
done
but in the folder with the tfs have nothing by gdb, like "core"./restart.sh: line 3: 74500 Segmentation fault ./tfs
.. help pls? :sProblemType: Crash
Architecture: arm64
CurrentDesktop: XFCE
Date: Tue Nov 29 06:00:18 2022
DistroRelease: Ubuntu 22.04
ExecutablePath: /var/www/ot/nost/tfs
ExecutableTimestamp: 1669666159
ProcCmdline: ./tfs
ProcCwd: /var/www/ot/nost
ProcEnviron:
SHELL=/bin/bash
LANG=C.UTF-8
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
PATH=(custom, no user)
ProcMaps:
73b532d92000-73b532e12000 rw-p 00000000 00:00 0
73b532e32000-73b533492000 rw-p 00000000 00:00 0
aaaad16a0000-aaaad1a55000 r-xp 00000000 08:01 1824881 /var/www/ot/nost/tfs
aaaad1a64000-aaaad1a73000 r--p 003b4000 08:01 1824881 /var/www/ot/nost/tfs
aaaad1a73000-aaaad1a74000 rw-p 003c3000 08:01 1824881 /var/www/ot/nost/tfs
aaaad1a74000-aaaad1a81000 rw-p 00000000 00:00 0
aaaafc8eb000-aaaafc932000 rw-p 00000000 00:00 0 [heap]
ffff20000000-ffff23279000 rw-p 00000000 00:00 0
ffff23279000-ffff24000000 ---p 00000000 00:00 0
ffff24000000-ffff24021000 rw-p 00000000 00:00 0
ffff24021000-ffff28000000 ---p 00000000 00:00 0
ffff28000000-ffff30000000 rw-p 00000000 00:00 0
ffff30000000-ffff38000000 rw-p 00000000 00:00 0
ffff38000000-ffff40000000 rw-p 00000000 00:00 0
ffff40000000-ffff48000000 rw-p 00000000 00:00 0
ffff48000000-ffff50000000 rw-p 00000000 00:00 0
ffff50000000-ffff58000000 rw-p 00000000 00:00 0
ffff58000000-ffff60000000 rw-p 00000000 00:00 0
ffff60000000-ffff68000000 rw-p 00000000 00:00 0
ffff68000000-ffff70000000 rw-p 00000000 00:00 0
ffff70000000-ffff78000000 rw-p 00000000 00:00 0
ffff78000000-ffff78021000 rw-p 00000000 00:00 0
ffff78021000-ffff7c000000 ---p 00000000 00:00 0
ffff7c000000-ffff80000000 rw-p 00000000 00:00 0
ffff80000000-ffff84000000 rw-p 00000000 00:00 0
ffff8684f000-ffff86a2d000 rw-p 00000000 00:00 0
ffff86a2d000-ffff86a3d000 ---p 00000000 00:00 0
ffff86a3d000-ffff8723d000 rw-p 00000000 00:00 0
ffff8723d000-ffff8724d000 ---p 00000000 00:00 0
ffff8724d000-ffff87a4d000 rw-p 00000000 00:00 0
ffff87a4d000-ffff87a5d000 ---p 00000000 00:00 0
ffff87a5d000-ffff8825d000 rw-p 00000000 00:00 0
ffff88490000-ffff8849d000 r-xp 00000000 08:01 40736 /usr/lib/aarch64-linux-gnu/libresolv.so.2
ffff8849d000-ffff884ad000 ---p 0000d000 08:01 40736 /usr/lib/aarch64-linux-gnu/libresolv.so.2
ffff884ad000-ffff884ae000 r--p 0000d000 08:01 40736 /usr/lib/aarch64-linux-gnu/libresolv.so.2
ffff884ae000-ffff884af000 rw-p 0000e000 08:01 40736 /usr/lib/aarch64-linux-gnu/libresolv.so.2
ffff884af000-ffff884b1000 rw-p 00000000 00:00 0
ffff884c0000-ffff88842000 r-xp 00000000 08:01 8336 /usr/lib/aarch64-linux-gnu/libcrypto.so.3
ffff88842000-ffff88852000 ---p 00382000 08:01 8336 /usr/lib/aarch64-linux-gnu/libcrypto.so.3
ffff88852000-ffff888a6000 r--p 00382000 08:01 8336 /usr/lib/aarch64-linux-gnu/libcrypto.so.3
ffff888a6000-ffff888a9000 rw-p 003d6000 08:01 8336 /usr/lib/aarch64-linux-gnu/libcrypto.so.3
ffff888a9000-ffff888ac000 rw-p 00000000 00:00 0
ffff888b0000-ffff8893d000 r-xp 00000000 08:01 8513 /usr/lib/aarch64-linux-gnu/libssl.so.3
ffff8893d000-ffff8894c000 ---p 0008d000 08:01 8513 /usr/lib/aarch64-linux-gnu/libssl.so.3
ffff8894c000-ffff88956000 r--p 0008c000 08:01 8513 /usr/lib/aarch64-linux-gnu/libssl.so.3
ffff88956000-ffff8895a000 rw-p 00096000 08:01 8513 /usr/lib/aarch64-linux-gnu/libssl.so.3
ffff88960000-ffff88a12000 r-xp 00000000 08:01 4944 /usr/lib/aarch64-linux-gnu/libzstd.so.1.4.8
ffff88a12000-ffff88a21000 ---p 000b2000 08:01 4944 /usr/lib/aarch64-linux-gnu/libzstd.so.1.4.8
ffff88a21000-ffff88a22000 r--p 000b1000 08:01 4944 /usr/lib/aarch64-linux-gnu/libzstd.so.1.4.8
ffff88a22000-ffff88a23000 rw-p 000b2000 08:01 4944 /usr/lib/aarch64-linux-gnu/libzstd.so.1.4.8
ffff88a30000-ffff88a31000 r-xp 00000000 08:01 40726 /usr/lib/aarch64-linux-gnu/libdl.so.2
ffff88a31000-ffff88a40000 ---p 00001000 08:01 40726 /usr/lib/aarch64-linux-gnu/libdl.so.2
ffff88a40000-ffff88a41000 r--p 00000000 08:01 40726 /usr/lib/aarch64-linux-gnu/libdl.so.2
ffff88a41000-ffff88a42000 rw-p 00001000 08:01 40726 /usr/lib/aarch64-linux-gnu/libdl.so.2
ffff88a50000-ffff88bd9000 r-xp 00000000 08:01 40724 /usr/lib/aarch64-linux-gnu/libc.so.6
ffff88bd9000-ffff88be8000 ---p 00189000 08:01 40724 /usr/lib/aarch64-linux-gnu/libc.so.6
ffff88be8000-ffff88bec000 r--p 00188000 08:01 40724 /usr/lib/aarch64-linux-gnu/libc.so.6
ffff88bec000-ffff88bee000 rw-p 0018c000 08:01 40724 /usr/lib/aarch64-linux-gnu/libc.so.6
ffff88bee000-ffff88bfa000 rw-p 00000000 00:00 0
ffff88c00000-ffff88c14000 r-xp 00000000 08:01 16970 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1
ffff88c14000-ffff88c23000 ---p 00014000 08:01 16970 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1
ffff88c23000-ffff88c24000 r--p 00013000 08:01 16970 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1
ffff88c24000-ffff88c25000 rw-p 00014000 08:01 16970 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1
ffff88c30000-ffff88e3a000 r-xp 00000000 08:01 8207 /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30
ffff88e3a000-ffff88e49000 ---p 0020a000 08:01 8207 /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30
ffff88e49000-ffff88e54000 r--p 00209000 08:01 8207 /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30
ffff88e54000-ffff88e57000 rw-p 00214000 08:01 8207 /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30
ffff88e57000-ffff88e5a000 rw-p 00000000 00:00 0
ffff88e60000-ffff88ed5000 r-xp 00000000 08:01 3753 /usr/lib/aarch64-linux-gnu/libgmp.so.10.4.1
ffff88ed5000-ffff88ee5000 ---p 00075000 08:01 3753 /usr/lib/aarch64-linux-gnu/libgmp.so.10.4.1
ffff88ee5000-ffff88ee6000 r--p 00075000 08:01 3753 /usr/lib/aarch64-linux-gnu/libgmp.so.10.4.1
ffff88ee6000-ffff88ee7000 rw-p 00076000 08:01 3753 /usr/lib/aarch64-linux-gnu/libgmp.so.10.4.1
ffff88ef0000-ffff88f27000 r-xp 00000000 08:01 45343 /usr/lib/aarch64-linux-gnu/libpugixml.so.1.12
ffff88f27000-ffff88f36000 ---p 00037000 08:01 45343 /usr/lib/aarch64-linux-gnu/libpugixml.so.1.12
ffff88f36000-ffff88f37000 r--p 00036000 08:01 45343 /usr/lib/aarch64-linux-gnu/libpugixml.so.1.12
ffff88f37000-ffff88f38000 rw-p 00037000 08:01 45343 /usr/lib/aarch64-linux-gnu/libpugixml.so.1.12
ffff88f40000-ffff892c1000 r-xp 00000000 08:01 23047 /usr/lib/aarch64-linux-gnu/libmysqlclient.so.21.2.31
ffff892c1000-ffff892d0000 ---p 00381000 08:01 23047 /usr/lib/aarch64-linux-gnu/libmysqlclient.so.21.2.31
ffff892d0000-ffff892d7000 r--p 00380000 08:01 23047 /usr/lib/aarch64-linux-gnu/libmysqlclient.so.21.2.31
ffff892d7000-ffff895c4000 rw-p 00387000 08:01 23047 /usr/lib/aarch64-linux-gnu/libmysqlclient.so.21.2.31
ffff895c4000-ffff895ca000 rw-p 00000000 00:00 0
ffff895d0000-ffff89656000 r-xp 00000000 08:01 40727 /usr/lib/aarch64-linux-gnu/libm.so.6
ffff89656000-ffff89665000 ---p 00086000 08:01 40727 /usr/lib/aarch64-linux-gnu/libm.so.6
ffff89665000-ffff89666000 r--p 00085000 08:01 40727 /usr/lib/aarch64-linux-gnu/libm.so.6
ffff89666000-ffff89667000 rw-p 00086000 08:01 40727 /usr/lib/aarch64-linux-gnu/libm.so.6
ffff89670000-ffff896ec000 r-xp 00000000 08:01 45290 /usr/lib/aarch64-linux-gnu/libluajit-5.1.so.2.1.0
ffff896ec000-ffff896fb000 ---p 0007c000 08:01 45290 /usr/lib/aarch64-linux-gnu/libluajit-5.1.so.2.1.0
ffff896fb000-ffff896fd000 r--p 0007b000 08:01 45290 /usr/lib/aarch64-linux-gnu/libluajit-5.1.so.2.1.0
ffff896fd000-ffff896fe000 rw-p 0007d000 08:01 45290 /usr/lib/aarch64-linux-gnu/libluajit-5.1.so.2.1.0
ffff89700000-ffff8971a000 r-xp 00000000 08:01 45169 /usr/lib/aarch64-linux-gnu/libboost_filesystem.so.1.74.0
ffff8971a000-ffff8972a000 ---p 0001a000 08:01 45169 /usr/lib/aarch64-linux-gnu/libboost_filesystem.so.1.74.0
ffff8972a000-ffff8972b000 r--p 0001a000 08:01 45169 /usr/lib/aarch64-linux-gnu/libboost_filesystem.so.1.74.0
ffff8972b000-ffff8972c000 rw-p 0001b000 08:01 45169 /usr/lib/aarch64-linux-gnu/libboost_filesystem.so.1.74.0
ffff8973d000-ffff89768000 r-xp 00000000 08:01 40721 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
ffff89768000-ffff89774000 rw-p 00000000 00:00 0
ffff89774000-ffff89776000 r--p 00000000 00:00 0 [vvar]
ffff89776000-ffff89777000 r-xp 00000000 00:00 0 [vdso]
ffff89777000-ffff89779000 r--p 0002a000 08:01 40721 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
ffff89779000-ffff8977b000 rw-p 0002c000 08:01 40721 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
ffff8c250000-ffff8c260000 r-xp 00000000 00:00 0
ffffcff8e000-ffffcffaf000 rw-p 00000000 00:00 0 [stack]
ProcStatus:
Name: tfs
Umask: 0002
State: D (disk sleep)
Tgid: 64026
Ngid: 0
Pid: 64026
PPid: 1617
TracerPid: 0
Uid: 1001 1001 1001 1001
Gid: 1001 1001 1001 1001
FDSize: 256
Groups: 4 20 24 25 27 29 30 44 46 118 119 1001
NStgid: 64026
NSpid: 64026
NSpgid: 1617
NSsid: 1611
VmPeak: 1695380 kB
VmSize: 1695380 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 1515516 kB
VmRSS: 1515516 kB
RssAnon: 1503236 kB
RssFile: 12280 kB
RssShmem: 0 kB
VmData: 1530848 kB
VmStk: 132 kB
VmExe: 3796 kB
VmLib: 14316 kB
VmPTE: 3068 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 1
THP_enabled: 1
Threads: 4
SigQ: 0/47480
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000100000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: thread vulnerable
SpeculationIndirectBranch: unknown
Cpus_allowed: 3
Cpus_allowed_list: 0-1
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 30
nonvoluntary_ctxt_switches: 1
Signal: 11
Uname: Linux 5.15.0-1022-oracle aarch64
UserGroups: adm audio cdrom dialout dip floppy lxd netdev plugdev sudo video
CoreDump: base64
(many other lines crypthed....)
/var/crash/
is probably from old crashes that happened before you disabled apport
.ulimit -c unlimited
core
file.ulimit -c unlimited
while true;
do ./tfs;
done
restart.sh
work, not only restart OTS.core
file on crash by crashing it using kill
command.ps -aux | grep tfs
tfs
with name of file you use to run OTS, it can be otservbr
, theforgottenserver
etc.)root@arm:~# ps -aux | grep tfs
root 105 0.0 0.0 0 0 ? S May09 0:00 [ecryptfs-kthrea]
root 1011530 6.1 1.2 461468 301632 pts/1 Sl+ Oct18 3872:01 ./tfs
root 1912976 0.0 0.0 7700 676 pts/0 R+ 22:21 0:00 grep --color=auto tfs
1011530
.kill -11 1011530
core
file, it should generate it.Updated code above. It'sjust informing. running this command asked for px installation
apt install px
running it again it doesn't tell me anything.
through htop I got the PID and executed kill -11 PID
and had a core dump, and a log generated.
now I will wait for the next crash to analyze. thank you very much @Gesior.pl
ps
, not px
nice man.. i'm looking the core."pid" but i cant open.. how read the error to analyze after??Updated code above. It'sps
, notpx
nice man.. i'm looking the core."pid" but i cant open.. how read the error to analyze after??
edit:
other thing. in htop I notice have 4 process to tfs..
the first one is the same appear on "ps -aux | grep tfs" and have 3 others...
i have only 1 cpu in this vps. is it right?
i have only 1 cpu in this vps. is it right?
- yes, but TFS 1.x runs on 4 threads (network thread, dispatcher thread, scheduler thread, database async thread), which are reported as processes on Linux how read the error to analyze after??
- gdb core tfs
(or gdb tfs core
I don't remember order) and then in gdb
terminal bt full
to generate reportOnly thing that can cause crash is bug in C++ (engine) or Lua (on TFS 1.x where Lua bugs can crash engine).ok, i will check when cracsh it..
relating to the other topic, do you think it is possible that what is causing a core dump is some attack? I'm going to start applying the rules..
I will extract the maximum knowledge from it. thanks master!Only thing that can cause crash is bug in C++ (engine) or Lua (on TFS 1.x where Lua bugs can crash engine).
Of course, some players know engine bugs and abuse them to crash OTSes, to clone items.
In some edge scenario: "number of connections is unlimited" - by default it's limited in Linux to 1024 per process - someone could make million connections to make server use gigabytes of RAM and crash by using all RAM, but I've never seen anything like that.
If you are interested in configuration of Linux (Ubuntu 20.04) for popular OTS:
It's in polish, but I know some people who configured their servers using this with Google Translate.tutorials/polish/konfiguracja-serwera-linux at master · gesior/tutorials
Contribute to gesior/tutorials development by creating an account on GitHub.github.com
There are not just some random commands, everything is described 'why I use this'.
and now? :s(gdb) (gdb) core core.85146
[New LWP 85147]
[New LWP 85149]
[New LWP 85146]
[New LWP 85148]
Core was generated by `./tfs'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000ffff9f893a40 in ?? ()
[Current thread is 1 (LWP 85147)]
Do this:dumped...
the log:
and now? :s
edit:
help pls.. i cant read the logs ;s