[wasm][http] Fix premature disposal of object causing crash in HttpClient #15018
Conversation
…g of the header object. - Use the iterator of the headers object do iteration over the fetch response headers.
|
@monojenkins build failed |
4 similar comments
|
@monojenkins build failed |
|
@monojenkins build failed |
|
@monojenkins build failed |
|
@monojenkins build failed |
baulig
left a comment
There was a problem hiding this comment.
I strongly dislike this approach. You are replacing a simple loop with a structure of three nested private classes - almost 300 lines of code - that's only used in one single place.
My biggest concern is that we're currently working on size reductions - and by adding something that looks hugely over-engineered and unnecessary to the naive observer - there is a risk that this will eventually get wiped out again during some optimization pass a couple of months down the line.
What I am currently doing is essentially going over each and every single class, asking the question "is this necessary or can it go away?"
From looking at this, I also don't understand why this is needed - how was the old code previously disposing objects and why do we need this private class instead of some more simple approach?
Will change this to simpler approach. |
- Use the Headers `entries{}` iterator object.
- This replaces the `foreach` delegate call where the object returned in the delegate was being disposed of too early.
- The foreach delegate takes three objects name, value, other. The `other` being disposed was causing a problem when calling back into the delegate later.
- Removes the lamda expression called by the delegate without the worry of a memory leak if the finally is removed.
|
Simplified the code. Ready to take another look when you want. |
Looks good :-) |
|
@monojenkins build failed |
Fix problem with fetch response header iteration prematurely disposing of headers object.
WasmHttpMessageHandler.csto use theHeadersiterator instead of it'sforEachmethod to iterate over the header values returned.Fixes: #14940