Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-13 Thread Alberto Garcia
Hey, first of all thanks a lot for sharing your findings! On Fri, May 09, 2014 at 08:14:41PM -0700, wh wrote: I only have one armel device. It's one of those super-cheap netbooks. Since the test passed for Alberto though, I have no idea what would cause it. I only tested it in a virtual

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-13 Thread wh
update: turns out you actually have to turn on the fixup trap $ echo 2 | sudo tee /proc/cpu/alignment 3 $ jsc '-ab'.match(/ab/) ab https://wiki.debian.org/ArmEabiFixes#word_accesses_must_be_aligned_to_a_multiple_of_their_size Though this wiki page recommends, you cannot rely on this being

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-11 Thread wh
This has been hard, because for some reason, in remote debugging, I can't step or continue once I've hit a breakpoint. Anyway, I've gotten through to the suspicious behavior by stepping through the assembly on the device. The weird stuff happens in YARR-generated code, so there's no symbols there

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-11 Thread wh
Here's a disassembly of the pattern /AT\W/i. http://paste.debian.net/98876/ High level overview: a loop starts at 0xb390a038. r0 is a pointer to the string, and r1 is the current search index plus 3. - it does a halfword load, converts it to lowercase, and checks it against at - if it's not

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-10 Thread wh
I made progress on getting gdb to work. It turns out I was loading the symbol file wrong, causing gdb to map it to the wrong address, which explains the Cannot access memory at messages. I'll try to step through starting at JSC::stringProtoFuncMatch to see what happens. No real findings so far.

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-09 Thread Alberto Garcia
On Thu, May 08, 2014 at 12:08:40PM -0700, wh wrote: welp, I'd better try debugging it or something. We would appreciate if you can keep us up-to-date with your findings (did you try in more machines? does it only fail in armel? etc.) Thanks! Berto -- To UNSUBSCRIBE, email to

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-09 Thread wh
I only have one armel device. It's one of those super-cheap netbooks. Since the test passed for Alberto though, I have no idea what would cause it. The test worked correctly on a amd64 virtual machine though. I made a few attempts to run jsc in gdb. First, there's not enough RAM on the device to

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-08 Thread Alberto Garcia
On Mon, May 05, 2014 at 05:57:04AM +, microrffr+deb...@gmail.com wrote: In jsc from libjavascriptcoregtk-3.0-bin: 'eat-'.match(/AT\W/i) null 'eeat-'.match(/AT\W/i) at- I cannot seem to reproduce this. $ jsc 'eat-'.match(/AT\W/i) at- 'eeat-'.match(/AT\W/i) at- $

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-08 Thread wh
welp, I'd better try debugging it or something. Thanks for trying it out. On Thu, May 8, 2014 at 6:15 AM, Alberto Garcia be...@igalia.com wrote: On Mon, May 05, 2014 at 05:57:04AM +, microrffr+debian@gmail.comwrote: In jsc from libjavascriptcoregtk-3.0-bin:

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

2014-05-05 Thread microrffr+debian
Package: libjavascriptcoregtk-3.0-0 Version: 2.4.1-2 Severity: normal Dear Maintainer, The following regular expression isn't matched right. It appears in test 26 of the Acid3 test. In jsc from libjavascriptcoregtk-3.0-bin: 'eat-'.match(/AT\W/i) null 'eeat-'.match(/AT\W/i)