625315 - Invalid ssize_t define on Windows x64

Status: RESOLVED FIXED

(Core :: Memory Allocator, defect)

Comment 1

[Makoto Kato [:m_kato]]

Attachment: fix v1

Comment 2

[Jason Evans]

Comment on attachment 503439 [details] [diff] [review]
fix v1

Is there really a system on which size_t is 64 bits, but long is only 32?  This seems unlikely to me, so some further explanation is needed before I'm comfortable with this patch.

Comment 3

[Makoto Kato [:m_kato]]

(In reply to comment #2)
> Comment on attachment 503439 [details] [diff] [review]
> fix v1
> 
> Is there really a system on which size_t is 64 bits, but long is only 32?  This
> seems unlikely to me, so some further explanation is needed before I'm
> comfortable with this patch.

Yes. Win64 compiler is LLP64 model, so size_t and pointer are 64-bit, but long is 32-bit.

Comment 4

[Makoto Kato [:m_kato]]

Jason, should I use MOZ_MEMORY_SIZEOF_PTR_2POW if it is defined?

Comment 5

[Makoto Kato [:m_kato]]

Attachment: fix v2

use MOZ_MEMORY_SIZEOF_PTR_2POW if available.

Comment 6

[Mats Palmgren (inactive)]

Wouldn't it be better to replace ssize_t with uintptr_t in rb.h instead?
(and s/size_t/intptr_t/ also for symmetry?)
That makes the bit-and operands use matching types intptr_t/uintptr_t which are
guaranteed to have the same size.
Then we can remove the local ssize_t typedef since it's not needed.

Comment 7

[Mats Palmgren (inactive)]

This bug blocks the #6 and #7 top crashes with 3.4% of 4.0b11pre crash incidents.

Comment 8

[Mats Palmgren (inactive)]

Jason ^

Comment 9

[Mats Palmgren (inactive)]

It seems likely this bug is also the root cause for incidents having
'malloc_rtree_set' in the signature, which sums up to another couple of
percent overall.

Comment 10

[Benjamin Smedberg]

oops, wrong flag

Comment 11

[Makoto Kato [:m_kato]]

http://hg.mozilla.org/mozilla-central/rev/82709dbd2c96