[Webkit-unassigned] [Bug 146440] Crash on xLarge memory allocation using bmalloc on 32bit systems

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=146440

--- Comment #6 from Mario Sanchez Prada <mario at webkit.org> ---
(In reply to comment #4)
> [...]
> What about setting this flag only for the bmalloc source files at
> Source/bmalloc/CMakeLists.txt . Would it be enough?

Not sure, but I will try that out just in case, I'd rather keep compiler optimizations enabled whenever/wherever possible. Thanks for the suggestion.

(In reply to comment #5)
> I think it'd be best to patch this downstream, unless we start getting
> additional bug reports; since you're the only one to have needed it so far,
> I guess it has likely already been fixed in GCC.

Not sure about this. While I understand this is a workaround and not the proper solution, this issue is not present just in our platform (where we use gcc 4.9) but also in Fedora, as you pointed out before, where you're using gcc 5.1.

The main difference between Fedora and our platform so far seems to be how likely the crash would happen. In our case it was happening always and that's why, even being quite sneaky, I managed to found a solution for it after all. But in other systems this can be very tricky to investigate, so perhaps it would be better to include the patch upstream, so that every single user would benefit of it?

Not 100% sure, would like to hear more opinions on this.

> Good job finding the exact optimization at fault; I don't want to think
> about how long you spent compiling. :(

Thanks. In the end it was not that terrible, the hardest part was before I stopped trying to debug the code and started looking at the compiler's optimizations. Once I figure out that -O1 would "cause" the crash, it was all much more simple :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150702/8289b4c0/attachment.html>