Segmentation Fault on Raspbian 10 with Raspberry 4 #4059

@bagasme commented on GitHub (Oct 4, 2019):

Still incomplete. Any logs from your Pi system before segfault?

@bagasme commented on GitHub (Oct 4, 2019): Still incomplete. Any logs from your Pi system before segfault?

GiteaMirror commented

@LuciferSam86 commented on GitHub (Oct 5, 2019):

No logs at all. Is there a method to debug the error?
edit: I got the error just trying to do ./gitea web after I downloaded the file without doing any kind of configuration.

On my Odroid XU4 with DietPi the same operation works without any error.

@LuciferSam86 commented on GitHub (Oct 5, 2019): No logs at all. Is there a method to debug the error? edit: I got the error just trying to do ./gitea web after I downloaded the file without doing any kind of configuration. On my Odroid XU4 with DietPi the same operation works without any error.

GiteaMirror commented

@steubner commented on GitHub (Oct 5, 2019):

The same error happens with the binary from 1.7.3 tested on a newley installed raspberrypi.

@steubner commented on GitHub (Oct 5, 2019): The same error happens with the binary from 1.7.3 tested on a newley installed raspberrypi.

GiteaMirror commented

@LuciferSam86 commented on GitHub (Oct 5, 2019):

@steubner Now I'm making another SD card with arch for raspi 4 and I'll update the main message.

@LuciferSam86 commented on GitHub (Oct 5, 2019): @steubner Now I'm making another SD card with arch for raspi 4 and I'll update the main message.

GiteaMirror commented

@LuciferSam86 commented on GitHub (Oct 5, 2019):

last update:
after I installed git, I run gitea under gdb and everything works. But when I execute outside gdb I got segmentation fault. I have a "core dump", who arch linux made. Here the dump: https://drive.google.com/open?id=1oP0KpZO4WfGo0lNk6cs45xAwgRP8w_Sp

@LuciferSam86 commented on GitHub (Oct 5, 2019): last update: after I installed git, I run gitea under gdb and everything works. But when I execute outside gdb I got segmentation fault. I have a "core dump", who arch linux made. Here the dump: https://drive.google.com/open?id=1oP0KpZO4WfGo0lNk6cs45xAwgRP8w_Sp

GiteaMirror commented

@guillep2k commented on GitHub (Oct 5, 2019):

The core file is useless to us without the whole environment (hardware, binaries) where it was run. But you can open it with gdb nonetheless and check it yourself. I think the syntax is something like:

gdb gitea core.xxxxxx
$ where

That should give you the stack trace of the function where the core was generated in text format. That we can use. 😁

@guillep2k commented on GitHub (Oct 5, 2019): The core file is useless to us without the whole environment (hardware, binaries) where it was run. But you can open it with gdb nonetheless and check it yourself. I think the syntax is something like: ``` gdb gitea core.xxxxxx $ where ``` That should give you the stack trace of the function where the core was generated in text format. That we can use. :grin:

GiteaMirror commented

@LuciferSam86 commented on GitHub (Oct 5, 2019):

The core file is useless to us without the whole environment (hardware, binaries) where it was run. But you can open it with gdb nonetheless and check it yourself. I think the syntax is something like:
gdb gitea core.xxxxxx
$ where
That should give you the stack trace of the function where the core was generated in text format. That we can use. 😁

Hi,
here the results:

Core was generated by `/home/alarm/gitea'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0118d598 in brk ()
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/alarm/gitea.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) where
#0  0x0118d598 in brk ()
#1  0x01167c14 in sbrk ()
#2  0x01140378 in __libc_setup_tls ()
#3  0x0113ff2c in __libc_start_main ()
#4  0x0001022c in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

@LuciferSam86 commented on GitHub (Oct 5, 2019): > > > The core file is useless to us without the whole environment (hardware, binaries) where it was run. But you can open it with gdb nonetheless and check it yourself. I think the syntax is something like: > > ``` > gdb gitea core.xxxxxx > $ where > ``` > > That should give you the stack trace of the function where the core was generated in text format. That we can use. 😁 Hi, here the results: ``` Core was generated by `/home/alarm/gitea'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0118d598 in brk () warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts of file /home/alarm/gitea. Use `info auto-load python-scripts [REGEXP]' to list them. (gdb) where #0 0x0118d598 in brk () #1 0x01167c14 in sbrk () #2 0x01140378 in __libc_setup_tls () #3 0x0113ff2c in __libc_start_main () #4 0x0001022c in _start () Backtrace stopped: previous frame identical to this frame (corrupt stack?) ```

GiteaMirror commented

@guillep2k commented on GitHub (Oct 5, 2019):

brk() is a linux system function that allocates space in memory. Your problem seems to happen way before the first line of Gitea code is ran, during libc initialization. Why it seemed to work from within gdb I don't know, but perhaps the running conditions where not exactly the same.

My guess is that there's something wrong with the linux libraries you have installed (e.g. a version mismatch). For example, you may have more than one version of the same library and Gitea is using "the wrong one" because its PATH variable is different or has different permissions (not as likely).

@guillep2k commented on GitHub (Oct 5, 2019): `brk()` is a linux system function that allocates space in memory. Your problem seems to happen way before the first line of Gitea code is ran, during `libc` initialization. Why it seemed to work from within gdb I don't know, but perhaps the running conditions where not exactly the same. My guess is that there's something wrong with the linux libraries you have installed (e.g. a version mismatch). For example, you may have more than one version of the same library and Gitea is using "the wrong one" because its `PATH` variable is different or has different permissions (not as likely).

GiteaMirror commented

@LuciferSam86 commented on GitHub (Oct 5, 2019):

This is a fresh mint installation of archlinux for arm and raspbian 10.

Any ideas?

Edit : gitea was executed as root

@LuciferSam86 commented on GitHub (Oct 5, 2019): This is a fresh mint installation of archlinux for arm and raspbian 10. Any ideas? Edit : gitea was executed as root

GiteaMirror commented

20003c4988/csu/libc-tls.c (L105)

@guillep2k commented on GitHub (Oct 5, 2019):

Besides the point that Gitea should not be ran as root (for obvious security reasons and unrelated to your problem) unfortunately I know very little about the raspbian environment (only what's generic to all Unixes). So, let's hope somebody else with more experience in that area can step in.

If it may give you any pointers, the problem seems to be related with the allocation for TLS functions:

But it may well be that memory was corrupted before that function is called.

@guillep2k commented on GitHub (Oct 5, 2019): Besides the point that Gitea should not be ran as root (for obvious security reasons and unrelated to your problem) unfortunately I know very little about the raspbian environment (only what's generic to all Unixes). So, let's hope somebody else with more experience in that area can step in. If it may give you any pointers, the problem seems to be related with the allocation for TLS functions: https://github.molgen.mpg.de/git-mirror/glibc/blob/20003c49884422da7ffbc459cdeee768a6fee07b/csu/libc-tls.c#L105 But it may well be that memory was corrupted *before* that function is called.

GiteaMirror commented

@steubner commented on GitHub (Oct 6, 2019):

The problem is related to the kernel version you are using.
On my pi running kernel version: 4.19.66-v7+ gitea is working without problems. The other two pi´s - where gitea gave the "segmentation fault" - are running kernel version: 4.19.75-v7+.

You can check it with following commands:
cat /proc/version
OR
uname -a

Therefore the workaround for the issue would be to go back to the old kernel version:
sudo apt reinstall raspberrypi-kernel=1.20190819-1 raspberrypi-bootloader=1.20190819-1

After the installation you need to reboot the pi.

Release information can be found at raspberrypi kernel project repo.

@steubner commented on GitHub (Oct 6, 2019): The problem is related to the kernel version you are using. On my pi running kernel version: 4.19.66-v7+ gitea is working without problems. The other two pi´s - where gitea gave the "segmentation fault" - are running kernel version: 4.19.75-v7+. You can check it with following commands: `cat /proc/version` OR `uname -a` Therefore the workaround for the issue would be to go back to the old kernel version: `sudo apt reinstall raspberrypi-kernel=1.20190819-1 raspberrypi-bootloader=1.20190819-1` After the installation you need to reboot the pi. Release information can be found at [raspberrypi kernel](https://github.com/raspberrypi/linux/releases) project repo.

GiteaMirror commented

@LuciferSam86 commented on GitHub (Oct 6, 2019):

Thank you. I'll open a ticket, there, too.

@LuciferSam86 commented on GitHub (Oct 6, 2019): Thank you. I'll open a ticket, there, too.

GiteaMirror commented

@lafriks commented on GitHub (Oct 11, 2019):

Not related to Gitea code or binary, if I understand correctly on referenced issue this has been fixed in latest kernel update

@lafriks commented on GitHub (Oct 11, 2019): Not related to Gitea code or binary, if I understand correctly on referenced issue this has been fixed in latest kernel update

GiteaMirror commented

@maicWorkGithub commented on GitHub (Dec 4, 2019):

raspberry is arm v7, should i use gitea-x.x.x-linux-arm-6 ?
download page have 10.0 and 10, that's very confused

@maicWorkGithub commented on GitHub (Dec 4, 2019): - raspberry is arm v7, should i use `gitea-x.x.x-linux-arm-6 `? - [download](https://dl.gitea.io/gitea/) page have `10.0` and `10`, that's very confused

GiteaMirror commented

@lunny commented on GitHub (Dec 4, 2019):

Yes, you should use arm-6 instead.

@lunny commented on GitHub (Dec 4, 2019): Yes, you should use arm-6 instead.

GiteaMirror commented

@xuenhua commented on GitHub (Dec 21, 2019):

Gitea version (or commit ref): 1.9.3

Git version: 2.20.1

Operating system: Raspbian 10

Database (use [x]):

PostgreSQL

MySQL

MSSQL

SQLite

Can you reproduce the bug at https://try.gitea.io:

Yes (provide example URL)

No

Not relevant

Log gist:

Description

Raspberry Pi 4 with Raspbian 10.
When I launch ./gitea I got "Segmentation Fault"

Used build: arm-6 downloaded from here: https://dl.gitea.io/gitea/1.9.3/gitea-1.9.3-linux-arm-6 .
...

Screenshots

N.A.

edit: I got the error just trying to do ./gitea web after I downloaded the file without doing any kind of configuration.
On my Odroid XU4 with DietPi the same operation works without any error.

edit 2 : the same error appears with Archlinux for Raspi 4. I'll do a gdb and I'll post the results in a gist

edit 3: sooo, after I installed git, I run under gdb and everything works. But when I execute outside gdb I got segmentation fault. I have a "core dump", who arch linux made. Here the dump: https://drive.google.com/open?id=1oP0KpZO4WfGo0lNk6cs45xAwgRP8w_Sp

The same issue

@xuenhua commented on GitHub (Dec 21, 2019): > * Gitea version (or commit ref): 1.9.3 > * Git version: 2.20.1 > * Operating system: Raspbian 10 > * Database (use `[x]`): > > * [ ] PostgreSQL > * [ ] MySQL > * [ ] MSSQL > * [ ] SQLite > * Can you reproduce the bug at https://try.gitea.io: > > * [ ] Yes (provide example URL) > * [ ] No > * [x] Not relevant > * Log gist: > > ## Description > Raspberry Pi 4 with Raspbian 10. > When I launch ./gitea I got "Segmentation Fault" > > Used build: arm-6 downloaded from here: https://dl.gitea.io/gitea/1.9.3/gitea-1.9.3-linux-arm-6 . > ... > > ## Screenshots > N.A. > > edit: I got the error just trying to do ./gitea web after I downloaded the file without doing any kind of configuration. > On my Odroid XU4 with DietPi the same operation works without any error. > > edit 2 : the same error appears with Archlinux for Raspi 4. I'll do a gdb and I'll post the results in a gist > > edit 3: sooo, after I installed git, I run under gdb and everything works. But when I execute outside gdb I got segmentation fault. I have a "core dump", who arch linux made. Here the dump: https://drive.google.com/open?id=1oP0KpZO4WfGo0lNk6cs45xAwgRP8w_Sp The same issue

GiteaMirror commented

@xuenhua commented on GitHub (Dec 21, 2019):

Yes, you should use arm-6 instead.

Raspberry 4's CPU is arm cortex-a72, I tried arm-6 ,arm-5 ,arm64 ,not work, please verify it‘s compatible with Raspberry 4

@xuenhua commented on GitHub (Dec 21, 2019): > Yes, you should use arm-6 instead. Raspberry 4's CPU is arm cortex-a72, I tried arm-6 ,arm-5 ,arm64 ,not work, please verify it‘s compatible with Raspberry 4

GiteaMirror commented

@techknowlogick commented on GitHub (Dec 21, 2019):

Arm6 works with rpi4, however the rpi4 introduced a big into their firmware that caused this issue for more than just Gitea. They have since patched the issue but an update to the firmware is needed

@techknowlogick commented on GitHub (Dec 21, 2019): Arm6 works with rpi4, however the rpi4 introduced a big into their firmware that caused this issue for more than just Gitea. They have since patched the issue but an update to the firmware is needed

GiteaMirror commented