On Tue, Jan 05, 2010 at 12:23:29AM +0300, Andrej Elizarov wrote: > >> ok. now to errors. > >> > >> i get some similiar to yours > >> https://bugs.webkit.org/show_bug.cgi?id=26099 > >> but now with 4(four) asserts and different line numbers. > >> i'll be more accurate when reproduce it. > > > > webkit-1.1.15.4/ $grep -r COMPILE_ASSERT . | wc -l > > 137 > hey, this is exactly the same error in the same file, take a look at > first message. > only different lines.
Hmpf, sorry. In fact, the fourth COMPILE_ASSERT appeared in r46589, which was a huge merge commit. yay for more comprehension. > > Yeah, you'll need to be more accurate.. if you reproduce it. > sure. > > > > >> Here > >> http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/ > >> appears some #def's and #ifdef's for OPENBSD, > >> may be it can be useful for breaking this bug(?) out. > > > > Can you be _more_ precise on where this ifdefs 'appear' ? as i'm > > probably the only one working on webkit/openbsd, and i didn't test > > 1.1.17 yet, i doubt that it targets this 'bug'. > http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/JavaScriptCore/jit/JITStubs.cpp yeah well, maybe change in r51141 might be related. Good luck understanding this asm mess. > > > >> comment out two blocks of code in my patch- may be valid only if : > >> #if COMPILER(GCC) && PLATFORM(X86) > >> #elif COMPILER(GCC) && PLATFORM(X86_64) > >> respectively > >> i'm surprised (see #uname output at top). > >> > >> meanwhile your asserts works only on > >> #elif COMPILER(GCC) && PLATFORM(X86_64) > >> and it's right imo. > > > > I don't get what you mean. > ok. > in my patch commented out two blocks of code. > first contained in: > #if COMPILER(GCC) && PLATFORM(X86) > //asserts > #endif > > and second one in: > #elif COMPILER(GCC) && PLATFORM(X86_64) > //asserts > #endif > > i have (X86) machine, but still need to comment out second block to > prevent errors, and it's weird. Agreed, totally. > > but in your case, as i see on > https://bugs.webkit.org/show_bug.cgi?id=26099 > there is only 125,126,127 lines in JavaScriptCore/jit/JITStubs.cpp > this lines correspond to > #elif COMPILER(GCC) && PLATFORM(X86_64) > //asserts > #endif > in > http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.10/JavaScriptCore/jit/JITStubs.cpp > and it's ok for you, as you use OpenBSD/amd64. Wait.. i always compile and test webkit on amd64/i386/powerpc before commiting the update. At that time, the asserts for X86 where here too, and i didn't get any report of problems so far on i386 without the patch snippet. Be it with 1.1.10 or 1.1.15 or 1.1.15.4... > > > >> i'm greping sources for layout of JITStackFrame, but no success for now. > >> may be there is things that i must to know about? > > > > JavaScriptCore/jit/JITStubs.h > oh, shame. tnx. > > > so, think we just need correct offset-values for code,savedEBX, > callFrame from "struct JITStackFrame". Err... what makes you think that particular struct members need a 'better' offset ? Try to reproduce the same issue with i386/-current, and we'll see if it's a real bug. Given the monster webkit is, i already lost way too many hours in it maintaining/testing it for -current, i won't spend time on frankeinstein -stable/-current mixes. You can still push the issue further in webkit bz. Landry
