lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: 64-bit linux errors with t/core/032-string_helper.t
Date Wed, 20 Jan 2010 05:17:58 GMT
On Tue, Jan 19, 2010 at 09:13:35PM -0600, Peter Karman wrote:

> Notice that 'i' just skips straight from 0 to 255.

That's certainly puzzling and troublesome.  It sounds like a stack corruption
bug -- as in the memory where the stack variable "i" resides is being
overwritten somehow.  I don't suppose valgrind turns anything up...

> When I comment out either of the UTF8_*[..] calls, then it works fine. It's 
> the combination of the two that causes the problem.

Oi.  Shades of that damn NetBSD nightmare...

> So there are no macros to affect that _local() function, and no vararg 
> oddities.

Well, don't shoot me but StrHelp_UTF8_TRAILING is actually a macro alias for
kino_StrHelp_UTF8_TRAILING, and printf is a variadic function so char arguments
such as StrHelp_UTF8_TRAILING[i] automatically get promoted to int.  We should
try to remove all varidic functions and all macro expansions from the

Clearly stuff like that *shouldn't* make a difference, but our local char
array works, and there's not much difference between what's happening there
and what's happening in these tests.

> However, when I put the same code into a standalone file and run it, it 
> works (see the test app I sent earlier in this thread with the UTF8 arrays 
> hardcoded).

Was this standalone file compiled with the same set of flags?  Maybe there's
some aggressive optimizer gone whack?

> I'm going to go drink a beer and try not to think about this madness for 
> awhile and hope that the answer just comes to me in my sleep.

Can we tag out?  If you can get me an account on one of these boxen, or if we
can duplicate this behavior on an Amazon EC2 instance, I'd like to take a
crack at it.

Marvin Humphrey

View raw message