[WebPositive] crashes in HTTPMediaIO::UpdateSize()

[diver]

Happened at ​https://arstechnica.com/

Debug information for team /boot/system/apps/WebPositive (2030):
CPU(s): 2x Intel Core™ i7-3635QM
Memory: 1.49 GB total, 549.04 MB used
Haiku revision: hrev55266 Jul 29 2021 07:15:13 (x86_64)

Active Threads:
	thread 2030: WebPositive (main)
	thread 2033: WebCore: IconDatabase 
	thread 2123: team 2030 debug task 
	thread 2035: w>Загрузки 
	thread 2037: w>Настройки 
	thread 2042: sort_thread 
	thread 2045: w>WebPositive: Сохранит 
	thread 2048: w>iPadOS 14.7 and macOS Big Sur 
	thread 2055: LocalStorage 
	thread 2067: BUrlProtocol.HTTP 
	thread 2074: JIT Worklist Helper Thread 
	thread 2075: JIT Worklist Helper Thread 
	thread 2076: CryptoQueue 
	thread 2078: IndexedDBServer 
	thread 2080: DataURLDecoder 
	thread 2108: BUrlProtocol.HTTP 
	thread 2109: BUrlProtocol.HTTP 
	thread 2110: BUrlProtocol.HTTP 
	thread 2111: BUrlProtocol.HTTP 
	thread 2114: BUrlProtocol.HTTP 
	thread 2115: BUrlProtocol.HTTP 
	thread 2116: BUrlProtocol.HTTP 
	thread 2117: BUrlProtocol.HTTP 
	thread 2118: BUrlProtocol.HTTP 
	thread 2119: BUrlProtocol.HTTP 
	thread 2120: BUrlProtocol.HTTP 
	thread 2121: BUrlProtocol.HTTP 
	thread 2122: data URL parser 
		state: Exception (Segment violation)

		Frame		IP			Function Name
		-----------------------------------------------
		0x7f75fbd914a0	0x15ddd1aff46	HTTPMediaIO::UpdateSize() + 0x16 
			Disassembly:
				HTTPMediaIO::UpdateSize():
				0x0000015ddd1aff30:               55  push %rbp
				0x0000015ddd1aff31:           4889e5  mov %rsp, %rbp
				0x0000015ddd1aff34:               53  push %rbx
				0x0000015ddd1aff35:           4889fb  mov %rdi, %rbx
				0x0000015ddd1aff38:         4883ec08  sub $0x8, %rsp
				0x0000015ddd1aff3c:         488b7f68  mov 0x68(%rdi), %rdi
				0x0000015ddd1aff40:           488b07  mov (%rdi), %rax
				0x0000015ddd1aff43:           ff5028  call 0x28(%rax)
				0x0000015ddd1aff46:           488b10  mov (%rax), %rdx <--

			Frame memory:
				[0x7f75fbd91480]  ....u....oV.$...   d8 14 d9 fb 75 7f 00 00 b0 6f 56 80 24 11 00 00
				[0x7f75fbd91490]   ...u...?.......   20 15 d9 fb 75 7f 00 00 3f fa b1 d4 fd 01 00 00
		0x7f75fbd91530	0x1fdd4b1fa3c	BPrivate::Network::BDataRequest::_ProtocolLoop() + 0xdc 
		0x7f75fbd91550	0x1fdd4b1f4d9	BPrivate::Network::BUrlRequest::_ThreadEntry(void*) + 0x29 
		0x7f75fbd91570	0x100c7a2a6a7	thread_entry + 0x17 
		00000000	0x7ffcd2837260	commpage_thread_exit + 0 

[smallstepforman]

It's quite easy to reproduce, just start any YouTube or Bitchute video. Web+ version 1.3-alpha, hrev55294

[vanitarium]

This bug has been blocking my tickets now twice.How to I know my bug report is the same as another bug beforehand??? The hardware here is different and the website too! This bug reporting is useless....I shall not report anything anymore if I am just blocked invoking duplication!!

[nephele]

vanitarium: The circumstances are different yes, but the issue is the same regardless. from a report from your ticket:

0x7fe5da3961f0  0x131bc4eff46   HTTPMediaIO::UpdateSize() + 0x16

this is the same function that this ticket is in reference to, and seeing by the number of blocked by you can see this is somewhat common :/

A ticket closed as duplicate is not a bad thing, it just means we already track it, and thus are aware of it, it doesn't mean there is anything wrong with the ticket per se.

[pulkomandy]

Yes, if you look at the bug report and see this somewhere in it: "HTTPMediaIO::UpdateSize()" it means it is the same bug and there is no need to report it again.

Sorry if there was not much explanation in your tickets about why it was closed as duplicate. It is easier for us to work this way (have a ticket and close it as a duplicate when we find out it is the same problem as another one) rather than the opposite way (have multiple problems discussed in one ticket, and then trying to understand which log corresponds to which problem).

Basically any website with audio or video in it is likely to have the same problem at the moment, and it seems no one had time yet to investigate it and understand what's happening.

You can vote for this ticket (using the arrows at the top right) to move it up in the "most voted tickets" list and it may help raise the attention of developers.

[waddlesplash]

I note this was first reported on 7/29, some 3 days after hrev55262, which seems suspicious. I have no idea how this commit could affect this, though.

[waddlesplash]

The crashes should be fixed as of hrev55399. However, at least for me, pages with audio or video now cause Web+ to hang in a "stuttering" fashion (for many seconds at a time.) I was testing in a single-core VM, though, so maybe it will work better for all of you?

[Coldfirex]

Arstechnica and all other websites mentioned in related tickets are loading correctly for me. Youtube also plays videos now. Well done!

[nephele]

Fixed in hrev55399. We can track stutering and such in another ticket, atleast for me plain html5 videos work fine now. :)

[waddlesplash]

Very good. Thanks for testing!