Opened 6 years ago

Closed 5 years ago

#10242 closed bug (fixed)

WebPositive crash in network backend (corrupted memory)

Reported by: stippi Owned by: pulkomandy
Priority: normal Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

From looking at the stack traces of the BUrlProtocol.HTTP threads, is there the same BString being modified concurrently?

Attachments (2)

WebPositive-3129-debug-24-11-2013-20-44-35.report (34.7 KB) - added by stippi 6 years ago.
Debugger crash report
WebPositive-1944-debug-21-12-2013-09-18-16.report (20.6 KB) - added by diver 5 years ago.

Download all attachments as: .zip

Change History (7)

Changed 6 years ago by stippi

Debugger crash report

comment:1 Changed 6 years ago by pulkomandy

Each of the BUrlProtocol.HTTP thread is bound to a BHttpRequest object and using the matching fOutputBuffer, so I don't think they are accessing the same string concurrently.

The intended use is: the output buffer is filled with the headers and request content, then the thread is started and reads from that string to send things over the network.

I will add some checks to make sure the string isn't modified again after the thread is started. Maybe a BMallocIO would be a better choice than a BString, as well.

comment:2 Changed 6 years ago by pulkomandy

I removed the fOutputBuffer BString in hrev46448, instead writing data directly into the socket. If anyone can reproduce this, an updated crash report is welcome.

comment:3 Changed 5 years ago by diver

I can reproduce it in hrev46573 by dragging /boot/system/data/gutenprint/dither-matrix-1x1.xml into Web+ window serveral (>3) times

comment:4 Changed 5 years ago by pulkomandy

Does this still happen on recent nightlies?

comment:5 Changed 5 years ago by diver

Resolution: fixed
Status: newclosed

It doesn't. Closing as fixed.

Note: See TracTickets for help on using tickets.