Impossible to terminate a blocked process

[fano]

If a process is blocked it seems there is no way to stop it!

For example I've see this with MediaPlayer and VLC today, this process hangs and you can close the windows, but the process not really terminate, it continue to run. The icon in twitcher is present as is in Process Controller, and if you do a ps, you see it.

Sadly if I choose "Quit Application" in twitcher or "Quit an application" or (very bad I've to do this) kill -9 PID on terminal, the process continue the execution as nothing happened.

Sorry to say this seems Windows like (a lot!) process is blocked and the user request terminatination and nothing happens!

The only way to terminate the application in this case is to reboot the machine, then an Alert appears saying "the application XXX is blocked maybe in a modal panel. You want to quit it?" If i choose to kill, now it terminates and the system is rebooted.

Obviusly the right beahvior is:

If the user want to terminates a blocked application all the way to terminate it should suceed! Not only when the system is rebooted, it is not important what was happening.

Maybe if an application is blocked (and the OS should know it) should be terminated automatically.

[stippi]

It depends of course how the application is blocked. Here you have experienced the same block in two different applications, because you were testing playback from UDF mounts. Usually, blocked processes can be killed just fine, but there are certain types of blocks in ther kernel, which make killing impossible. This results from a bug in a kernel component, most likely the UDF add-on, and does not represent the average blocked process.

AFA automatic detection of hanged processes goes... this is possible to implement. One way to do it is to regularily ping the application thread (perhaps all window threads as well) with messages that have an expected reply timeout. Also, app_server could expect a reply for the quit message that it sends when the user presses the window close button. If a reply does not arrive within a certain timeout, it could offer to kill the team. Some programs could need to be updated, though, since they may do stuff that appears as blocking, like asking the user to save changes, the user could be navigating a file dialog to save his work, it would be irritating to popup an alert asking to force kill the app right then...

[fano]

Yes "automatic detected of hanged process" is a delicate thing... as you saying if the user close the application and it ask to save something and the user does nothing, the application can appear blocked from the system perspective? Have I understand well? If the save dialog is on the application appears as blocked?

I think it depends how the application is implemented... not should be a thread to respond to system messages?

Maybe something "low level" that not rely on the way the program is done?

I don't know... the impression was not good (as I said resemble Windows behavior: user don't count) and I think some solution must be found...

[fano]

Maybe for now a sort of ACK at the termination request should be implemented and in the case of no ACK is received in let my say 1 second kill forcefully the application (after ask the user if he it sure)!

The application should respond NACK too... the OS know then that is not really blocked but busy for now!

I think in the shutdown/reboot routine something similar shoul be already present: in that case the OS tried to KILL Mediaplayer and then recognize it can't and offer the user the possibility to destroy it! And it does it.

[bonefish]

Can we please not mix things in this ticket. That a process cannot be killed (as opposed to quit) is an unacceptable kernel or driver bug. Let's focus on that. Detecting unresponsive applications is something else entirely and more of a missing feature (though applications -- at least the ones included in Haiku simply shouldn't hang in the first place). Feel free to open a new ticket for that, if there is none yet.

You have set the version to "R1/alpha1". Is the problem reproducible with a more recent revision? A more detailed description of how your situation can be reproduced would be appreciated. At least I've never seen VLC or MediaPlayer hang in a way that they couldn't be killed (though, admittedly, I haven't used them very often). Stippi brought up UDF, though I can't see any mention of it in the ticket description. Were you playing back (media files from) a DVD?

After you've established that a process cannot be killed (BTW, one can kill also using ProcessController (via the "Threads and CPU usage" menu)) a stack trace of all threads of that application would be helpful for analyzing the problem. You can get those in the kernel debugger: Enter it via Alt-SysReq-D. Use the "teams" command to get a list of all running teams and find the ID of team in question. Use "threads <team ID>" to get the list of threads of the team. Use "bt <thread ID>" to get a stack trace for each thread. Leave the kernel debugger with the "co" command. After a few seconds all the output from the kernel debugger should have made it to /var/log/syslog. Append the file to the ticket. Thanks!

[fano]

The version I was testing was not R1/alpha1, but hrev35923, I have forgotten to say that essential info!

Blocks were probably related to UDF kernel driver problems, see ​http://dev.haiku-os.org/ticket/4601 for more information.

The processes (Mediaplayer and VLC in this case) can't killed in ANY way:

• Twitcher "Quit application" (right click on the process icon) does nothing
• ProcessController "Quit an application" and choosing the blocked application does nothing
• The kill -9 PID from terminal DOES nothing...

I'll try to do the suggested tests and to generate a backtrace ASAP.

[fano]

Very High SD AVI (All the DVD size is taken by a 4.37 GB AVI file)

[fano]

This is obtained playing a 4.37 GB 720p MKV file

[fano]

This obtained palying the second VOB of a DVD... in this case Mediaplayer start but only green pixels appears on screen!

[fano]

I've attached the requested syslog files.

I hope they will be useful to solve the problem.

Some information about the file I'm trying to play:

1. AVI at High bitrate (>4000 maybe), the video format is SD and the audio is AC3. Mediaplayer plays only some seconds of video very slow (1-2 fps) and then the screen became GRAY and hangs
   
2. MKV video is H264 at 1280x720 of resolution. Mediaplayer remains in the state "Opening" forever
   
3. DVD not crypted the first file is played in the video part, the audio (AC3 audio, secodn trak DTS is not recognized) is out of sync end echoed. If I try to close the program it closes, in this case! Trying to open the second VOB (VTS01_2,vob) is very problematic indeed, Mediaplayer shows only green pixels... nothing else. Trying to close has the expected result, nothing happens...

[bonefish]

The interesting part from the first syslog:

KERN: atapi 5-0 error: device indicates transfer error after dma
KERN: check_sense: Medium error
KERN: usb error ehci 1: KERN: qtd (0x03d04700) error: 0x800d8d40
KERN: usb_disk: operation 0x35 failed at the SCSI level
KERN: usb error ehci 1: qtd (0x03d12e80) error: 0x000d8d40
KERN: usb_disk: operation 0x35 failed at the SCSI level
KERN: usb error ehci 1: qtd (0x03d16680) error: 0x800d8d40
KERN: usb_disk: operation 0x35 failed at the SCSI level
KERN: usb error ehci 1: qtd (0x03d1a480) error: 0x800d8d40
KERN: usb_disk: operation 0x35 failed at the SCSI level
KERN: usb error ehci 1: KERN: qtd (0x03d1e280) error: 0x800d8d40
KERN: usb_disk: operation 0x35 failed at the SCSI level

and:

KERN: kdebug> bt 224
stack trace for thread 224 "media extractor thread"
KERN:     kernel stack: 0xcd9c2000 to 0xcd9c6000
KERN:       user stack: 0x70145000 to 0x70185000
KERN: frame               caller     <image>:function + offset
KERN:  0 cd9c5964 (+  48) 80069413   <kernel_x86> context_switch(thread*: 0xcdd2e000, thread*: 0xcd31b800) + 0x003f
KERN:  1 cd9c5994 (+  96) 800697e4   <kernel_x86> reschedule() + 0x038c
KERN:  2 cd9c59f4 (+  64) 8003ee9d   <kernel_x86> ConditionVariableEntry<0xcd9c5a68>::Wait(uint32:KERN:  0x0 (0), int64: 0) + 0x01a1
KERN:  3 cd9c5a34 (+  80) 8008eb38   <kernel_x86> IORequest<0xcd9c5ab0>::Wait(uint32: 0x0 (0), int64: 0) + 0x00ac
KERN:  4 cd9c5a84 (+ 192) 800b3aec   <kernel_x86>:vfs_read_pages + 0x0078
KERN:  5 cd9c5b44 (+ 496) 8003b058   <kernel_x86> read_into_cache(file_cache_ref*: 0xcce33370, NULL, int64: 588881920, int32: 3018, uint32: 0x1809c670, uint32: 0x10000 (65536), true, vm_page_reservation*: 0xcd9c5de8, uint32: 0x0 (0)) + 0x01a8
KERN:  6 cd9c5d34 (+ 192) 8003c225   <kernel_x86> cache_io(0xcce33370, NULL, int64: 588947456, uint32: 0x180abaa6, 0xcd9c5f2c, false) + 0x06d9
KERN:  7 cd9c5df4 (+  80) 8003cc1a   <kernel_x86>:file_cache_read + 0x0036
KERN:  8 cd9c5e44 (+  64) 8169ae60   </boot/system/add-ons/kernel/file_systems/iso9660> fs_read(fs_volume*: 0xccdb7ca8, fs_vnode*: 0xcce2ccc0, 0x1, int64: 588884938, 0x1809c670, 0xcd9c5f2c) + 0x0074
KERN:  9 cd9c5e84 (+  64) 800b5787   <kernel_x86> file_read(file_descriptor*: 0xcce33cd0, int64: 588884938, 0x1809c670, 0xcd9c5f2c) + 0x0067
KERN: 10 cd9c5ec4 (+  80) 800a2651   <kernel_x86> common_user_io(int32: 3, int64: 588884938, 0x1809c670, uint32: 0x10000 (65536), false) + 0x017d
KERN: 11 cd9c5f14 (+  48) 800a2aec   <kernel_x86>:_user_read + 0x0028
KERN: 12 cd9c5f44 (+ 100) 800fa4a2   <kernel_x86>:handle_syscall + 0x00af

First of all, this is obviously not UDF related, since it is not even used (ISO9660 is, as we see in the stack trace). Furthermore it seems to be an issue in a lower layer.

Am I assuming correctly that you use a USB connected DVD drive?

[fano]

No, there is not a real USB DVD drive but effectively the USB boot key is a U3 Sandisk: it a "composite device" a part of it should appear to the OS a CD/DVD drive and the rest is a normal USB disk.

​http://en.wikipedia.org/wiki/U3

...and incidentally the CD part is not recognized as a real CDROM (no CD icon) but only as a USB key as if thre was 2 one is "Haiku" and the CD in another!

In my case there is no launchpad installed on the CD/DVD part but an Windows XP installer disk...

Haiku in installed on the data partition of the USB key.

The files I was trying to playing was DVD inserted in a normal internal IDE DVD Drive... and the DVD itselfs was formatted in UDF, so why "media extractor thread" was using ISO9660? I'm sure of UDF as ISO has 2 GB size limit, so I can't write those files in a ISO DVD.

Is somewhat confused from the U3 CD/USB combination or it is misinterpreting the UDF DVD?

Maybe I should try removing the DVD/CD part from the USB key... should it lead to confusion?

[bonefish]

Replying to fano:

The files I was trying to playing was DVD inserted in a normal internal IDE DVD Drive... and the DVD itselfs was formatted in UDF, so why "media extractor thread" was using ISO9660? I'm sure of UDF as ISO has 2 GB size limit, so I can't write those files in a ISO DVD.

The ISO 9660 level 2 file size limit is actually 4 GB (unsigned 32 bit integer), level 3 lifts that limit to several TB (though I don't think Haiku supports that ATM). Often DVDs are UDF/ISO 9660 hybrids, so that they can be mounted as either one. Under Haiku UDF should be preferred, though, if the FS module does correctly recognize the disk that is. According to the syslog it doesn't, though:

KERN:   trying: file_systems/iso9660/v1
KERN: identify(1, 0xccd1f820)
KERN: found primary descriptor
KERN:   iso9660_primary_descriptor:
KERN:     volume descriptor type: 1 (primary)
KERN:     standard identifier:    CD001 (valid)
KERN:     version:                1
KERN:     identifier:             'LA_COMPAGNIA_                   '
KERN:     size:                   2033024
KERN:     set size:               1
KERN:     sequence number:        1
KERN:     logical block size:     2048
KERN:     path table size:        10
KERN:     set identifier:                                     
KERN:     root directory record:
KERN:       length:               34
KERN:       location:             19
KERN:       data length:          2048
KERN:       volume space:         1
KERN: iso9660_info::set_string(0xccd1f820 ('<NULL>'), 'LA_COMPAGNIA_                   ', 13)
KERN:   returned: 0.6
KERN:   trying: file_systems/nfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/ntfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/reiserfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/udf/v1
KERN: 
KERN: udf_recognize: Block size must be a positive power of two! (blockSize = 882)

Is somewhat confused from the U3 CD/USB combination or it is misinterpreting the UDF DVD?

Maybe I should try removing the DVD/CD part from the USB key... should it lead to confusion?

No idea. Assigning to mmlr. Maybe he has a clue.

[fano]

Then Haiku is right the first DVD (AVI High Bitrate) is in ISO9660 format (I not remembered correctly I've to divide it in 3 file of 1.4 GB and use ISO format Divx players had problems with UDF disk!), the second has only a 4.37 GB Mkv on it and is recognized by Nero "Disk Info" as "UDF (mode 1)", the 3th is a real DVD video (that is with the VIDEO TS and Audio TS folders) and is recognized as hybrid ("UDF/ISO 9660 (mode 1)").

So maybe is not a UDF driver problem at the end, but something else...

[noak]

Maybe for now a sort of ACK at the termination request should be implemented and in the case of no ACK is received in let my say 1 second kill forcefully the application (after ask the user if he it sure)!

The application should respond NACK too... the OS know then that is not really blocked but busy for now!

I think in the shutdown/reboot routine something similar shoul be already present: in that case the OS tried to KILL Mediaplayer and then recognize it can't and offer the user the possibility to destroy it! And it does it. Greetigns from ​London

[bonefish]

Replying to noak:

Maybe for now a sort of ACK at the termination request should be implemented and in the case of no ACK is received in let my say 1 second kill forcefully the application (after ask the user if he it sure)!

This has nothing to do with this ticket. Please read comment:4.

[Arnold]

In R1A3 in Virtualbox on MacOSX. Webpositive hanging and no way to terminate kill the application. No windows open for I closed them for Web+ did not respond any more. This is after Terminal with Installoptionalpackages -h (cut and paste the command from the included welcome/user guide pages) and -l. While restarting the system the message about modal panel is shown.