Re: still getting errors with CRM

Very good spotting there, Bill :-)


On Tue, Apr 29, 2008 at 2:19 AM, Jason Lewis <[email protected]> wrote:
[...]
>  So what do I do to test or fix this?

Umm... well, that may have to wait (car is waiting, gotta go) unless
Paolo and/or BillY feel like taking a stab at this.
When I'm back in 2 weeks and things are not resolved by then, I'll
take a look and see if the fixes in the attached files are enough for
your (Jason) issue.

Meanwhile, to answer Paolo: I'm sorry, the latter. (expandvar is ever
so slightly b0rked).

Anyway, my current belief is this is not a 64-bit only issue, but does
happen in a very particular fringe case where the first character
beyond the valid string is a '\' backslash, causing expandvar to grab
stuff from the uninitialized and ILLEGAL string bay area.


For non-tech-hackers:

please wait for a fix. This email contains a lead or two, but no
'ready made' stuff, because I don't have the time right now. :-((



For tech hackers:

For those who have tracked the GerH builds a little: you may have
noticed that several bits and pieces in there were already fixed a few
months ago. My bad luck is that it was rather hard to provide
reproducible scripts for the fringe cases occurring and when I was
fixing the buggers I was in a hurry because I wanted my stuff to
_work_ _now_!
Bottom line is that Bill got hammered by a few diffs you can paper
your kid's new room in and consequently little follow-up after that.

The most recent challenge (convert binary 32-bit input to 'eval'-able
numbers - or just hexdumped) found me hitting a few more snags in the
GerH code at this same spot: developers may like to check the diff:
the latest buggers in there are the discoveries (I'm amazed it took me
so long before finally eradicating that cruft) that the loops all go
'one beyond' the allowable buffer range, causing all kinds of wicked
havoc, especially when you 'clean' the code a bit like I did. (The
original 'fixups' in there do not work 100% of the time - see Jason's
issue which is one of those 'out of bounds' issues, which (warning:
diving deep into tech land) is 'intermittant because it depends on the
actual state of the stack and heap bytes in the momentanely invalid
zone, which WILL be 'random' and DIFFERS across runs. Why? Because the
OS will NOT initialize the binary at the very same memory address each
and every time, leading to pointer values being slightly different
each time, depending on the circumstances. Machines are deterministic,
but they are big enough in this regard to be close to magic to relate
to a quote from Einstein. Anyway, the issue ONLY pops up when one of
those bytes out there (the one AFTER the last valid byte in the string
to expand) was initialized _before_ with a backslash byte value,
causing expandvar to 'see' an (invalid) escaped character entity where
it shouldn't and thus screwing up the expanded string; since the
escape is not 'valid', the backslash gets copied into the output, as
spotted by Bill.
Long story. Yada yada yada.

Anyway: the diff has it.


Cave Canem. YMMV. Note that this diff comes from a VERY flaky GerH
build which I decided not to release just now as it would only mess
things up, CRM_MAX and ASSERT macros in there are GerH style and will
not compile out of the box for vanilla crm114 as that one doesn't know
those. However when the need arrises, anyone can re-implement the
CRM_MAX() macro as it's a simple 'MAX(a,b)' statement and when you
don't love 'em, kick out the ASSERTs, though your debug builds may not
catch a few buggers still hanging around then.


Now I jump into my car and drive off - hope I'm not shot when I get
back to this ML. ;-)



Gotta run,

Ger

PS: sent to you personally too in case the ML yacks because of the
attachment size; don't have time to do that 'nicely' so here's making
sure the usual suspects got something that might be worth
investigating.





>
>  Jason
>
>
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Crm114-general mailing list
>  [email protected]
>  https://lists.sourceforge.net/lists/listinfo/crm114-general
>
>
>



-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Crm114-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crm114-general