Re: [webkit-dev] Stability problems involving Javascript GC
On 6 December 2010 22:31, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Crash in WTF::fastMalloc? Such things only happen if something overwrites memory areas belongs to the memory manager (i.e overwrites some bytes before or after a block returned by malloc). Try some valgrind equivalent on mac to detect those writings into red zones. How can you use valgrind to help on that? We had some symptoms similar to this and also came to the conclusion that probably something is overwriting the structures used by fast malloc, but couldn't find anything with valgrind. Overwriting in an area that has bee reserved is not an error vangrind finds, at least not with any options that I know. I haven't received your reply before. To capture this bug, you have to disable fastmalloc, and use the internal (trackable) memory allocator replacement of valgrind. Run build-webkit --system-malloc This will redirect all allocations to the system malloc. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
I haven't received your reply before. To capture this bug, you have to disable fastmalloc, and use the internal (trackable) memory allocator replacement of valgrind. Run build-webkit --system-malloc This will redirect all allocations to the system malloc. Thanks. That's a good point. I already tested the system without fast-malloc, but it didn't reproduce the crash in that configuration so I didn't thought of valgrinding it. I'll give it a try Cheers -- Samuel Rivas RD and Base Development Leader m:+34 619 92 77 46 t:+34 981 17 33 44 ext:61 www.lambdastream.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
It is possible to add macros to the code to help valgrind know which areas are being used by a custom allocator. (See VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK, for example.) I'm not sure if they're useful in this situation, but they're worth taking a look at. I see. That would discover errors such as something overwriting structures allocated by the allocator but that were not handled to the application, right? Is there any reason why that's not included in the webkit allocator? I mean apart from lack of time/interest, of course. Regards -- Samuel Rivas RD and Base Development Leader m:+34 619 92 77 46 t:+34 981 17 33 44 ext:61 www.lambdastream.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
It is possible to add macros to the code to help valgrind know which areas are being used by a custom allocator. (See VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK, for example.) I'm not sure if they're useful in this situation, but they're worth taking a look at. I see. That would discover errors such as something overwriting structures allocated by the allocator but that were not handled to the application, right? Is there any reason why that's not included in the webkit allocator? I mean apart from lack of time/interest, of course. I don't think that would be useful. Real allocators do several optimizations, which could hide many errors. An example: p = malloc(100); free(p); p = malloc(100); I clever allocator would probably return with the same pointer. However, valgrind wants to detect unintended access to freed blocks, so its allocator would never reuse the same address if possible. Moreover, it skips X bytes before and after the block to detect overwrite / underwrite situations (red zones). Thus, we should use the system malloc if possible (captured and redirected by valgrind). And leave that macro to those cases, where the software is designed to not use system malloc (garbage collected memory areas for example). Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about StringImpl::create
On Dec 16, 2010, at 10:36 PM, Gavin Barraclough wrote: The short answer is that String::format should be considered deprecated - its behavior is platform-specific, and we'd like to move away from it. We should probably put a comment in WTFString.h that says something along these lines. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build Slave Shutdown
On Thu, Dec 16, 2010 at 3:05 PM, William Siegrist wsiegr...@apple.com wrote: Our buildbot allows for anonymous people to trigger things on the slaves, and it is like this on purpose for ease of use. However, that means it is possible for a malicious person to do things like shutdown all of the slaves. That is what happened last night around 10:30pm PST, from 66.57.13.12, and that is why the slaves are offline. Something weird happened when the EFL slave was shut down. It runs as an unprivileged user, but for some reason, the log file (twisted.log) and various other files inside the SVN checkout were owned by root. I initially thought the other admin restarted the buildslave service as root by mistake, but this isn't the case. I've fixed the permissions and the buildslave is up and running again, but I'm still a bit worried about this. chkrootkit does not ring any bells, and disk corruption is unlikely as this is both pontual and the slave is an Amazon EC2 instance. Quick searches on Google didn't return anything useful, so I ask: have things like this happened before? Thanks, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build Slave Shutdown
On Dec 17, 2010, at 11:53 AM, Leandro Pereira wrote: On Thu, Dec 16, 2010 at 3:05 PM, William Siegrist wsiegr...@apple.com wrote: Our buildbot allows for anonymous people to trigger things on the slaves, and it is like this on purpose for ease of use. However, that means it is possible for a malicious person to do things like shutdown all of the slaves. That is what happened last night around 10:30pm PST, from 66.57.13.12, and that is why the slaves are offline. Something weird happened when the EFL slave was shut down. It runs as an unprivileged user, but for some reason, the log file (twisted.log) and various other files inside the SVN checkout were owned by root. I initially thought the other admin restarted the buildslave service as root by mistake, but this isn't the case. I've fixed the permissions and the buildslave is up and running again, but I'm still a bit worried about this. chkrootkit does not ring any bells, and disk corruption is unlikely as this is both pontual and the slave is an Amazon EC2 instance. Quick searches on Google didn't return anything useful, so I ask: have things like this happened before? No, it sounds like buildbot was run as root at some point. Maybe the owner(s) of the other slaves can chime in about this happening. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitTools has changed to Tools
Done in r74301. On Nov 20, 2010, at 11:29 PM, Dan Bernstein wrote: WebKit developers, I am going to commit the patch from https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools directory to Tools and updating all internal references. If you update your tree after that, you might need to adjust any personal scripts or tools that refer to the old name. I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST). Regards, —Dan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
