Opened 8 months ago

Last modified 6 months ago

#14887 new bug

Haiku randomly crashes when executing terminal commands

Reported by: Undoified Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86-64

Description (last modified by humdinger)

Haiku randomly crashes when executing some terminal commands (usally comands that execute multiple other command, such as neofetch and config scripts) and when starting the terminal. The entire system, or perhaps just the graphics, freezes.

This only occurs on x86_64 running natively (doesn't happen running in a virtual machine).
My computer has a FX 6300 prossesor, an RX 560 graphics card, and is running hrev52837.

Attachments (1)

previous_syslog (175.3 KB ) - added by Undoified 8 months ago.

Download all attachments as: .zip

Change History (17)

comment:1 by humdinger, 8 months ago

You may want to have a look at the syslogs in /var/logs/ so see if the crashes are logged there and upload it here. Maybe you have assigned not enough RAM for the virtual environment? Also make sure in Haiku's VirtualMemory preferences, that VM is activated.

comment:2 by alpopa, 8 months ago

Does the problem persists when using single CPU boot option?

by Undoified, 8 months ago

Attachment: previous_syslog added

in reply to:  1 ; comment:3 by Undoified, 8 months ago

Replying to humdinger:

You may want to have a look at the syslogs in /var/logs/ so see if the crashes are logged there and upload it here. Maybe you have assigned not enough RAM for the virtual environment? Also make sure in Haiku's VirtualMemory preferences, that VM is activated.

I purposly crashed Haiku and uploaded the syslog, and it appears to be a problem with BFS. I appear to have made a typo on the ticket - this only happens on hardware, and doesn't occur when using a virtual machine.

in reply to:  2 ; comment:4 by Undoified, 8 months ago

Replying to alpopa:

Does the problem persists when using single CPU boot option?

No, it does not.

in reply to:  3 ; comment:5 by humdinger, 8 months ago

Component: Applications/Terminal- General
Description: modified (diff)
Milestone: R1/beta2Unscheduled
Owner: changed from jackburton to nobody
Priority: highnormal

Replying to Undoified:

I purposly crashed Haiku and uploaded the syslog, and it appears to be a problem with BFS.

Do a backup of important files, then try a "checkfs /boot" (or maybe "checkfs -c /boot" first for a testrun).

I appear to have made a typo on the ticket - this only happens on hardware, and doesn't occur when using a virtual machine.

I changed the text accordingly.

in reply to:  4 ; comment:6 by alpopa, 8 months ago

Replying to Undoified:

Replying to alpopa:

Does the problem persists when using single CPU boot option?

No, it does not.

In this case, the bug may be the same, or have the same root cause, as in #10279.

in reply to:  5 comment:7 by Undoified, 8 months ago

Replying to humdinger:

Replying to Undoified:

I purposly crashed Haiku and uploaded the syslog, and it appears to be a problem with BFS.

Do a backup of important files, then try a "checkfs /boot" (or maybe "checkfs -c /boot" first for a testrun).

I appear to have made a typo on the ticket - this only happens on hardware, and doesn't occur when using a virtual machine.

I changed the text accordingly.

I ran checkfs. It had no effect, which doesn't really surprise me considering the issue is still present on a clean install of Haiku.

in reply to:  6 comment:8 by Undoified, 8 months ago

Replying to alpopa:

Replying to Undoified:

Replying to alpopa:

Does the problem persists when using single CPU boot option?

No, it does not.

In this case, the bug may be the same, or have the same root cause, as in #10279.

I think its probably related, but I'm not entirely convinced its the same bug. #10279 is blocked by #14082 which includes some attachments of kdl output, however when my system crashes i don't receive any kdl output. Python seems stable to me, which it isn't under #10279.

comment:9 by waddlesplash, 8 months ago

Blocked By: 14718 added

Probably this is the same as #14718, though, which has the same kind of lockup.

I've found some hardware this is easily reproducible on by changing HDA settings. However I have no idea what's going on, and the fact that KDL is not enterable via the emergency keys in this state make it notoriously difficult to debug.

comment:10 by waddlesplash, 8 months ago

I recently committed hrev52883 which might catch this as a panic (unlikely, it's probably some more nefarious issue.) Please test on that if you can.

Also, the output of listimage | grep kernel on a completely idle system would be helpful.

in reply to:  9 comment:11 by diver, 8 months ago

Replying to waddlesplash:

I've found some hardware this is easily reproducible on by changing HDA settings.

This is #9560.

comment:12 by waddlesplash, 8 months ago

I don't think so, I don't get a kernel crash, just a deadlock. KDL is definitely working, as I can drop into it before triggering the lock, but then afterwards I can't. So it's not a page fault.

comment:13 by waddlesplash, 8 months ago

The top 2 commits in hrev52902 will catch more cases of illegal context switches, which may help with diagnosing this.

comment:14 by tqh, 7 months ago

Blocked By: 14718 removed

comment:15 by waddlesplash, 6 months ago

hrev53046 and hrev53041 add some more asserts here. Please retest after that.

comment:16 by alpopa, 6 months ago

(Also added this comment to #14082)

Retested hrev53092 on AMD Phenom II x4 955. I can compile from Terminal large projects, and compilation takes several (tens of) minutes with no problem. However, when trying to grep something simple, the system restarts instantly.

Edit: grep worked after that without problem. It may be a sporadical reboot, or some problem in grep (first time I used its argument without quotes, later I used them) or in file system.

Last edited 6 months ago by alpopa (previous) (diff)
Note: See TracTickets for help on using tickets.