Debug surfaceflinger crash

[Rahul Jain]

Hello All,

I am trying to debug surfaceflinger crash issue. The problem occurs in some opengl call because of my change in GL driver and due to which the libui is crashing and surfaceflinger keeps restarting,so the desktop never boots up. In logcat I can see the backtrace but I want to attach it to debugger.

Is there any way to attach it to debugger and stop on fault to check the backtrace?

Seems like service manager keeps surfaceflinger restart. I assume there may be some property which can hold hi on crash.

Any suggestions?

[Mauro Rossi]

Hi,

When SurfaceFlinger crashes, you should see debug lines/backtrace of crash ( segfault SIGSEGV ) in /data/log.txt  (boot in DEBUG mode required)

The crashes also generate a tombstone_xx file in /data/tombstones

So the following commands should help:

cat /data/log.txt | less


cat /data/tombstones/tombstone_00 | less  

Once you identify the library involved in the crash, you can use addr2line command to find the line of code involved in the crash.

Looking in the tombstone file you will see in the backtrace the addresses like (the following are examples

 

0000000001111111 in /system/vendor/lib64/egl/libGLES_mesa.so

0000000002222222 in /system/vendor/lib64/dri/gallium_dri.so

cd android-x86 (the root of the repo)
addr2line -Cfe out/target/product/x86_64/symbols//system/vendor/lib64/egl/libGLES_mesa.so
0000000001111111[ENTER]
[you will get the line corresponding to backtrace entry]
CTRL+C


addr2line -Cfe out/target/product/x86_64/symbols/system/vendor/lib64/dri/gallium_dri.so
0000000002222222[ENTER]
[you will get the line corresponding to backtrace entry]
CTRL+C

[Rahul Jain]

Hi Mauro,

On Fri, Mar 13, 2020, 05:48 Mauro Rossi <issor...@gmail.com> wrote:

Hi,

On Thursday, March 12, 2020 at 7:27:08 PM UTC+1, Rahul Jain wrote:

Hello All,

I am trying to debug surfaceflinger crash issue. The problem occurs in some opengl call because of my change in GL driver and due to which the libui is crashing and surfaceflinger keeps restarting,so the desktop never boots up. In logcat I can see the backtrace but I want to attach it to debugger.

Is there any way to attach it to debugger and stop on fault to check the backtrace?

Seems like service manager keeps surfaceflinger restart. I assume there may be some property which can hold hi on crash.

Any suggestions?

When SurfaceFlinger crashes, you should see debug lines/backtrace of crash ( segfault SIGSEGV ) in /data/log.txt  (boot in DEBUG mode required)

You mean to say I should boot in debug mode at time of boot, but when we boot to debug mode seems like we get the console and surfaceflinger is not launched, I may be wrong. 😊

The crashes also generate a tombstone_xx file in /data/tombstones

So the following commands should help:

cat /data/log.txt | less


cat /data/tombstones/tombstone_00 | less  

Once you identify the library involved in the crash, you can use addr2line command to find the line of code involved in the crash.

Looking in the tombstone file you will see in the backtrace the addresses like (the following are examples

 

0000000001111111 in /system/vendor/lib64/egl/libGLES_mesa.so

0000000002222222 in /system/vendor/lib64/dri/gallium_dri.so

cd android-x86 (the root of the repo)
addr2line -Cfe out/target/product/x86_64/symbols//system/vendor/lib64/egl/libGLES_mesa.so
0000000001111111[ENTER]
[you will get the line corresponding to backtrace entry]
CTRL+C


addr2line -Cfe out/target/product/x86_64/symbols/system/vendor/lib64/dri/gallium_dri.so
0000000002222222[ENTER]
[you will get the line corresponding to backtrace entry]
CTRL+C

I will try this one soon, but isn't it possible to attach gdb and debug the crash ? I tried it once but as it restarts the netd also restarts and my gdb remote target get broken.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/a41bec55-41a5-41c8-9183-ed896ce6a9f7%40googlegroups.com.

[Mauro Rossi]

On Friday, March 13, 2020 at 4:17:16 AM UTC+1, Rahul Jain wrote:

Hi Mauro,

On Fri, Mar 13, 2020, 05:48 Mauro Rossi <issor...@gmail.com> wrote:

Hi,

On Thursday, March 12, 2020 at 7:27:08 PM UTC+1, Rahul Jain wrote:

Hello All,

I am trying to debug surfaceflinger crash issue. The problem occurs in some opengl call because of my change in GL driver and due to which the libui is crashing and surfaceflinger keeps restarting,so the desktop never boots up. In logcat I can see the backtrace but I want to attach it to debugger.

Is there any way to attach it to debugger and stop on fault to check the backtrace?

Seems like service manager keeps surfaceflinger restart. I assume there may be some property which can hold hi on crash.

Any suggestions?

When SurfaceFlinger crashes, you should see debug lines/backtrace of crash ( segfault SIGSEGV ) in /data/log.txt  (boot in DEBUG mode required)

You mean to say I should boot in debug mode at time of boot, but when we boot to debug mode seems like we get the console and surfaceflinger is not launched, I may be wrong. 😊

The commands described are for [ALT]+[F1] console

 

The crashes also generate a tombstone_xx file in /data/tombstones

So the following commands should help:

cat /data/log.txt | less


cat /data/tombstones/tombstone_00 | less  

Once you identify the library involved in the crash, you can use addr2line command to find the line of code involved in the crash.

Looking in the tombstone file you will see in the backtrace the addresses like (the following are examples

 

0000000001111111 in /system/vendor/lib64/egl/libGLES_mesa.so

0000000002222222 in /system/vendor/lib64/dri/gallium_dri.so

cd android-x86 (the root of the repo)
addr2line -Cfe out/target/product/x86_64/symbols//system/vendor/lib64/egl/libGLES_mesa.so
0000000001111111[ENTER]
[you will get the line corresponding to backtrace entry]
CTRL+C


addr2line -Cfe out/target/product/x86_64/symbols/system/vendor/lib64/dri/gallium_dri.so
0000000002222222[ENTER]
[you will get the line corresponding to backtrace entry]
CTRL+C

I will try this one soon, but isn't it possible to attach gdb and debug the crash ? I tried it once but as it restarts the netd also restarts and my gdb remote target get broken.

I don't know if those service are available at that stage,

I usually insert and mount an USB flash drive with commands:

cd /data; mkdir x; busybox mount /dev/block/sdc1 /data/x

[Rahul Jain]

On Fri, Mar 13, 2020, 18:51 Mauro Rossi <issor...@gmail.com> wrote:

On Friday, March 13, 2020 at 4:17:16 AM UTC+1, Rahul Jain wrote:

Hi Mauro,

On Fri, Mar 13, 2020, 05:48 Mauro Rossi <issor...@gmail.com> wrote:

Hi,

On Thursday, March 12, 2020 at 7:27:08 PM UTC+1, Rahul Jain wrote:

Hello All,

I am trying to debug surfaceflinger crash issue. The problem occurs in some opengl call because of my change in GL driver and due to which the libui is crashing and surfaceflinger keeps restarting,so the desktop never boots up. In logcat I can see the backtrace but I want to attach it to debugger.

Is there any way to attach it to debugger and stop on fault to check the backtrace?

Seems like service manager keeps surfaceflinger restart. I assume there may be some property which can hold hi on crash.

Any suggestions?

When SurfaceFlinger crashes, you should see debug lines/backtrace of crash ( segfault SIGSEGV ) in /data/log.txt  (boot in DEBUG mode required)

You mean to say I should boot in debug mode at time of boot, but when we boot to debug mode seems like we get the console and surfaceflinger is not launched, I may be wrong. 😊

The commands described are for [ALT]+[F1] console

Ye right I get it now. 😊

 

The crashes also generate a tombstone_xx file in /data/tombstones

So the following commands should help:

cat /data/log.txt | less


cat /data/tombstones/tombstone_00 | less  

Once you identify the library involved in the crash, you can use addr2line command to find the line of code involved in the crash.

Looking in the tombstone file you will see in the backtrace the addresses like (the following are examples

 

0000000001111111 in /system/vendor/lib64/egl/libGLES_mesa.so

0000000002222222 in /system/vendor/lib64/dri/gallium_dri.so

cd android-x86 (the root of the repo)
addr2line -Cfe out/target/product/x86_64/symbols//system/vendor/lib64/egl/libGLES_mesa.so
0000000001111111[ENTER]
[you will get the line corresponding to backtrace entry]
CTRL+C


addr2line -Cfe out/target/product/x86_64/symbols/system/vendor/lib64/dri/gallium_dri.so
0000000002222222[ENTER]
[you will get the line corresponding to backtrace entry]
CTRL+C

I will try this one soon, but isn't it possible to attach gdb and debug the crash ? I tried it once but as it restarts the netd also restarts and my gdb remote target get broken.

I don't know if those service are available at that stage,

I usually insert and mount an USB flash drive with commands:

cd /data; mkdir x; busybox mount /dev/block/sdc1 /data/x

Sorry, I didn't get this, how do it help with respect to debug surfaceflinger?

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/be0b1905-66ed-4214-995d-e5e04fec21df%40googlegroups.com.

[Mauro Rossi]

I usually insert and mount an USB flash drive with commands:

cd /data; mkdir x; busybox mount /dev/block/sdc1 /data/x

Sorry, I didn't get this, how do it help with respect to debug surfaceflinger?

These commands allow to mount USB drive to a folder in /data (sdc1 may change in your case, you will see the drive when plugging the USB drive with console) 

after that you can copy  /data/log.txt and /data/tombstones/* files to USB drive,

in case you need to recover those logs.

Mauro