[Interest] ASSERT / Debug Crash in Qt 5.3.2. WTF, Windows x64, LLIntData.cpp at bitwise_cast<uint32_t*>(&testVector)[sizeof(void*)/sizeof(uint32_t) + 1] == 42)

[Andre Barth]

Hi Allan,

castResult[3] is indexResult - forgot to print that explicitly; sorry

indexedResult
0xcccccccc

Anyway:
Here's the complete layout
&testVector
0x000000000026e8e8 {m_size=42 }
    WTF::VectorBuffer<int,0>: {...}
    m_size: 42
&testVector.m_size
0x000000000026e8f8 {42}
&testVector.m_capacity
0x000000000026e8f0 {42}

And memory: (0x000000000026E8E8  is &testVector)
0x000000000026E8E8  | 06339100 00000000 0000002a cccccccc 0000002a cccccccc cccccccc

Again, maybe this all is false alarm, b/c I messed something up with the build... But the only thing I basically did for QWebKit was 

DEFINES += ENABLE_JIT=0 ENABLE_YARR_JIT=0 ENABLE_ASSEMBLER=0

Thanks,
Andre

-----Original Message-----
From: Allan Sandfeld Jensen [mailto:carewolf at gmail.com] On Behalf Of Allan Sandfeld Jensen
Sent: Friday, October 10, 2014 4:25 PM
To: Andre Barth
Cc: interest at qt-project.org
Subject: Re: [Interest] ASSERT / Debug Crash in Qt 5.3.2. WTF, Windows x64, LLIntData.cpp at bitwise_cast<uint32_t*>(&testVector)[sizeof(void*)/sizeof(uint32_t) + 1] == 42)

Hi Andre

That all looks reasonable, but what is in castResult[3] ?

It expected to look like this:
void * m_buffer [int index 0-1]
uint m_capacity [int index 2]
int m_size [int index 3]

where m_capacity on Linux is 44, but m_size is 42.

`Allan

On Friday 10 October 2014, Andre Barth wrote:
> Hi Allan,
> 
> Thanks for the prompt response. I will go ahead & log a bug.
> 
> FWIW - Below is some test output.
> 
> Thanks,
> Andre
> 
> //some changed test code:
> Vector<int> testVector;
> testVector.resize(42);
> 
> auto sizeOfCalc = (sizeof(void*)/sizeof(uint32_t) + 1);
> 
> auto address  = &testVector;
> auto castResult = bitwise_cast<uint32_t*>(&testVector);
> auto indexedResult = castResult[sizeOfCalc];
> 
> bool result = (indexedResult == 42);
> 
> //and the corresponding "online" checks & results...
> 
> sizeof(void*)
> 0x0000000000000008
> 
> sizeof(uint32_t)
> 0x0000000000000004
> 
> sizeOfCalc
> 0x0000000000000003
> 
> address
> 0x00000000002ce7d8 {m_size=0x0000002a }
>     WTF::VectorBuffer<int,0>: {...}
>     m_size: 0x0000002a
> 
> castResult
> 0x00000000002ce7d8 {0x083f8450}
> 
> indexedResult
> 0xcccccccc
> 
> castResult[0]
> 0x083f8450
> 
> castResult[1]
> 0x00000000
> 
> castResult[2]
> 0x0000002a
> 
> 
> -----Original Message-----
> From: Allan Sandfeld Jensen [mailto:carewolf at gmail.com] On Behalf Of 
> Allan Sandfeld Jensen Sent: Friday, October 10, 2014 3:09 PM
> To: interest at qt-project.org
> Cc: Andre Barth
> Subject: Re: [Interest] ASSERT / Debug Crash in Qt 5.3.2. WTF, Windows 
> x64, LLIntData.cpp at
> bitwise_cast<uint32_t*>(&testVector)[sizeof(void*)/sizeof(uint32_t) + 
> 1] == 42)
> 
> On Friday 10 October 2014, Andre Barth wrote:
> > Hi all,
> > 
> > I built a JIT-free version of Qt 5.3.2 (Win64) and now run into this 
> > assertion in
> > 
> > ..\Qt\qtwebkit\Source\JavaScriptCore\llint\LLIntData.cpp
> > 
> > Vector<int> testVector;
> > testVector.resize(42);
> > ASSERT(bitwise_cast<uint32_t*>(&testVector)[sizeof(void*)/sizeof(uin
> > t3
> > 2_t)+
> > 
> >  1] == 42);
> > 
> > Here is a bug report / changeset I've found wrt this:
> > 
> > http://trac.webkit.org/changeset/148896/trunk/Source/JavaScriptCore/
> > ll
> > int/L
> > LIntData.cpp
> > 
> > and
> > 
> > https://bugs.webkit.org/show_bug.cgi?id=97268
> > 
> > The assert is supposed to check, that the Vector's m_size variable 
> > is at the correct address, I guess?!
> > 
> > If not, anyone can shed a light on this and explain the purpose of 
> > it and where I might have incorrect compilation settings applied?
> > 
> > Am I missing somewhere an alignment pragma or something to make this
> > (sizeof(void*)/sizeof(uint32_t))
> > always calculate the right address - regardless of whether its x86 
> > or x64?
> 
> There are some differences between alignment and exact types between 
> linux
> x64 and win x64. Could you test what (sizeof(void*)/sizeof(uint32_t)) 
> is, and what is on the first few ints of the address of Vector<int> 
> after a resize(42)?
> 
> Anyway, it might we worth opening a bug for to track the issue. Even 
> if the assert turns out to be harmless, the binaries should be able to 
> run in debug versions (even win64).
> 
> `Allan