<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>149061</bug_id>
          
          <creation_ts>2015-09-11 04:32:12 -0700</creation_ts>
          <short_desc>[ARM] REGRESSION(r189575): It made 2860 tests fail/crash on AArch64 Linux</short_desc>
          <delta_ts>2015-11-12 01:58:01 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>JavaScriptCore</component>
          <version>Other</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>DUPLICATE</resolution>
          <dup_id>150936</dup_id>
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>108645</blocked>
    
    <blocked>148666</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter name="Csaba Osztrogonác">ossy</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>clopez</cc>
    
    <cc>fpizlo</cc>
    
    <cc>mark.lam</cc>
    
    <cc>msaboff</cc>
    
    <cc>ossy</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1125166</commentid>
    <comment_count>0</comment_count>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2015-09-11 04:32:12 -0700</bug_when>
    <thetext>Unfortunately I can&apos;t add the details to the bug report, because 
https://build.webkit.org/waterfall is out of order again and again. :-/</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1125167</commentid>
    <comment_count>1</comment_count>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2015-09-11 04:37:37 -0700</bug_when>
    <thetext>Ah, build.webkit.org works again, so here is the link about this regression:
https://build.webkit.org/builders/EFL%20Linux%20AArch64%20Release/builds/3270

I tested manually, everything works fine on r189574, but there 
are 2860 failures/crash on r189575 (with its buildfix r189588

I&apos;m going to investigate this issue and try to provide
debug build logs and/or other useful information.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1125175</commentid>
    <comment_count>2</comment_count>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2015-09-11 06:39:20 -0700</bug_when>
    <thetext>Unfortunately I can&apos;t reproduce this bug in debug mode. :(
I will try to reproduce it on a relase build with debug symbols.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1125202</commentid>
    <comment_count>3</comment_count>
    <who name="Michael Saboff">msaboff</who>
    <bug_when>2015-09-11 09:48:29 -0700</bug_when>
    <thetext>While debugging the callee saves work, I would run into failures on release builds that wouldn&apos;t reproduce with debug builds.  Typically this was due to the optimizer making use of callee saves registers in the compiled C++ code.  If JSC inadvertently stepped on one of those registers, it would only cause a problem on release builds.

The first place I would look is in the FTL code.  For example, I didn&apos;t test any of the changes to the Linux specific code in FTLUnwindInfo.cpp.  See if failing tests work when the FTL is turned off.

One technique that I used to track down these kinds of problems was to add back in the saving and restoring of callee saves to the pushCalleeSaves() / popCalleeSaves() macros in LowLevelInterpreter.asm and then in LowLEvelInterpreter64.asm:doVMEntry, write sentinel numeric values to the callee saves registers, e.g. 0x1019 to x19, 0x1020 to x20, ... After &quot;makeCall()&quot; in doVMEntry and at the beginning of _handleUncaughtException, compare the values with a breakpoint on mismatch.  I made a macro to do the testing.  That did 2 things, first it allowed building with debug.  But probably more useful was that at any point executing in the JavaScript VMs I could look at the registers to see that they had the sentinel values were they should.  I could also check the CallFrames that we saved the sentinel values where appropriate.  I&apos;ll post a patch with this technique that I used for X86-64 debugging.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1125204</commentid>
    <comment_count>4</comment_count>
      <attachid>261007</attachid>
    <who name="Michael Saboff">msaboff</who>
    <bug_when>2015-09-11 09:50:48 -0700</bug_when>
    <thetext>Created attachment 261007
Patch used for X86-64 Callee Saves debugging</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1125920</commentid>
    <comment_count>5</comment_count>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2015-09-15 02:59:46 -0700</bug_when>
    <thetext>(In reply to comment #3)
&gt; While debugging the callee saves work, I would run into failures on release
&gt; builds that wouldn&apos;t reproduce with debug builds.  Typically this was due to
&gt; the optimizer making use of callee saves registers in the compiled C++ code.
&gt; If JSC inadvertently stepped on one of those registers, it would only cause
&gt; a problem on release builds.
&gt; 
&gt; The first place I would look is in the FTL code.  For example, I didn&apos;t test
&gt; any of the changes to the Linux specific code in FTLUnwindInfo.cpp.  See if
&gt; failing tests work when the FTL is turned off.
&gt; 
&gt; One technique that I used to track down these kinds of problems was to add
&gt; back in the saving and restoring of callee saves to the pushCalleeSaves() /
&gt; popCalleeSaves() macros in LowLevelInterpreter.asm and then in
&gt; LowLEvelInterpreter64.asm:doVMEntry, write sentinel numeric values to the
&gt; callee saves registers, e.g. 0x1019 to x19, 0x1020 to x20, ... After
&gt; &quot;makeCall()&quot; in doVMEntry and at the beginning of _handleUncaughtException,
&gt; compare the values with a breakpoint on mismatch.  I made a macro to do the
&gt; testing.  That did 2 things, first it allowed building with debug.  But
&gt; probably more useful was that at any point executing in the JavaScript VMs I
&gt; could look at the registers to see that they had the sentinel values were
&gt; they should.  I could also check the CallFrames that we saved the sentinel
&gt; values where appropriate.  I&apos;ll post a patch with this technique that I used
&gt; for X86-64 debugging.

Thanks for the ideas and the patch for debugging.

I didn&apos;t check the FTL code yet, because it is disabled by default on Linux.
I don&apos;t know if it works at all, I didn&apos;t check it in the latest 4-5 months.

But it seems the bug is in the DFG tier somewhere, because tests pass with
(build time) disabled DFG. (except ~20 tests) And I already managed to catch
register mismatches with the idea you suggested. I&apos;ll continue debugging in
the near future.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1141420</commentid>
    <comment_count>6</comment_count>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2015-11-12 01:58:01 -0800</bug_when>
    <thetext>https://trac.webkit.org/changeset/192352 already fixed this issue.
Sometimes Linux failures point out real but hidden failure on iOS. ;)

before: https://build.webkit.org/builders/EFL%20Linux%20AArch64%20Release/builds/4313 - 3227 failures
after: https://build.webkit.org/builders/EFL%20Linux%20AArch64%20Release/builds/4314 - 52 failures

The remaining failures might be related to this issue or can be a 
different issue, who knows what else happened in the latest 2 months.

I&apos;m going to file a new bug report for the remaining failures.

*** This bug has been marked as a duplicate of bug 150936 ***</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>261007</attachid>
            <date>2015-09-11 09:50:48 -0700</date>
            <delta_ts>2015-09-14 03:47:50 -0700</delta_ts>
            <desc>Patch used for X86-64 Callee Saves debugging</desc>
            <filename>test-debug-callee-saves.patch</filename>
            <type>text/plain</type>
            <size>3828</size>
            <attacher name="Michael Saboff">msaboff</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9sbGludC9Mb3dMZXZlbEludGVycHJldGVyNjQu
YXNtCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9sbGludC9Mb3dMZXZlbElu
dGVycHJldGVyNjQuYXNtCShyZXZpc2lvbiAxODg5MDMpCisrKyBTb3VyY2UvSmF2YVNjcmlwdENv
cmUvbGxpbnQvTG93TGV2ZWxJbnRlcnByZXRlcjY0LmFzbQkod29ya2luZyBjb3B5KQpAQCAtMTE0
LDEwICsxMTQsMjQgQEAgbWFjcm8gY0NhbGw0KGZ1bmN0aW9uKQogICAgIGVuZAogZW5kCiAKK21h
Y3JvIGNoZWNrUmVnVmFsdWUocmVnLCB2YWx1ZSwgdGVtcCkKKyAgICBtb3ZlIHZhbHVlLCB0ZW1w
CisgICAgYnBlcSB0ZW1wLCByZWcsIC52YWx1ZU9LCisgICAgYnJlYWsKKyAgICBtb3ZlIHJlZywg
dDEKKy52YWx1ZU9LOgorZW5kCisKIG1hY3JvIGRvVk1FbnRyeShtYWtlQ2FsbCkKICAgICBmdW5j
dGlvblByb2xvZ3VlKCkKICAgICBwdXNoQ2FsbGVlU2F2ZXMoKQogCisgICAgbW92ZSAweDEwMCwg
Y3NyMAorICAgIG1vdmUgMHgxMDEsIGNzcjEKKyAgICBtb3ZlIDB4MTAyLCBjc3IyCisgICAgbW92
ZSAweDEwMywgY3NyMworICAgIG1vdmUgMHgxMDQsIGNzcjQKKwogICAgIGNvbnN0IGVudHJ5ID0g
YTAKICAgICBjb25zdCB2bSA9IGExCiAgICAgY29uc3QgcHJvdG9DYWxsRnJhbWUgPSBhMgpAQCAt
MTcwLDYgKzE4NCwxMiBAQCBtYWNybyBkb1ZNRW50cnkobWFrZUNhbGwpCiAKICAgICBzdWJwIGNm
ciwgQ2FsbGVlUmVnaXN0ZXJTYXZlU2l6ZSwgc3AKIAorICAgIGNoZWNrUmVnVmFsdWUoY3NyMCwg
MHgxMDAsIHQ0KQorICAgIGNoZWNrUmVnVmFsdWUoY3NyMSwgMHgxMDEsIHQ0KQorICAgIGNoZWNr
UmVnVmFsdWUoY3NyMiwgMHgxMDIsIHQ0KQorICAgIGNoZWNrUmVnVmFsdWUoY3NyMywgMHgxMDMs
IHQ0KQorICAgIGNoZWNrUmVnVmFsdWUoY3NyNCwgMHgxMDQsIHQ0KQorCiAgICAgcG9wQ2FsbGVl
U2F2ZXMoKQogICAgIGZ1bmN0aW9uRXBpbG9ndWUoKQogICAgIHJldApAQCAtMjM0LDYgKzI1NCwx
MiBAQCBtYWNybyBkb1ZNRW50cnkobWFrZUNhbGwpCiAKICAgICBzdWJwIGNmciwgQ2FsbGVlUmVn
aXN0ZXJTYXZlU2l6ZSwgc3AKIAorICAgIGNoZWNrUmVnVmFsdWUoY3NyMCwgMHgxMDAsIHQ0KQor
ICAgIGNoZWNrUmVnVmFsdWUoY3NyMSwgMHgxMDEsIHQ0KQorICAgIGNoZWNrUmVnVmFsdWUoY3Ny
MiwgMHgxMDIsIHQ0KQorICAgIGNoZWNrUmVnVmFsdWUoY3NyMywgMHgxMDMsIHQ0KQorICAgIGNo
ZWNrUmVnVmFsdWUoY3NyNCwgMHgxMDQsIHQ0KQorCiAgICAgcG9wQ2FsbGVlU2F2ZXMoKQogICAg
IGZ1bmN0aW9uRXBpbG9ndWUoKQogCkBAIC0yNzUsNiArMzAxLDEzIEBAIF9oYW5kbGVVbmNhdWdo
dEV4Y2VwdGlvbjoKICAgICBhbmRwIE1hcmtlZEJsb2NrTWFzaywgdDMKICAgICBsb2FkcCBNYXJr
ZWRCbG9jazo6bV93ZWFrU2V0ICsgV2Vha1NldDo6bV92bVt0M10sIHQzCiAgICAgcmVzdG9yZUNh
bGxlZVNhdmVzRnJvbVZNQ2FsbGVlU2F2ZXNCdWZmZXIodDMsIHQwKQorCisgICAgY2hlY2tSZWdW
YWx1ZShjc3IwLCAweDEwMCwgdDQpCisgICAgY2hlY2tSZWdWYWx1ZShjc3IxLCAweDEwMSwgdDQp
CisgICAgY2hlY2tSZWdWYWx1ZShjc3IyLCAweDEwMiwgdDQpCisgICAgY2hlY2tSZWdWYWx1ZShj
c3IzLCAweDEwMywgdDQpCisgICAgY2hlY2tSZWdWYWx1ZShjc3I0LCAweDEwNCwgdDQpCisKICAg
ICBsb2FkcCBWTTo6Y2FsbEZyYW1lRm9yVGhyb3dbdDNdLCBjZnIKIAogICAgIGxvYWRwIENhbGxl
ckZyYW1lW2Nmcl0sIGNmcgpJbmRleDogU291cmNlL0phdmFTY3JpcHRDb3JlL2xsaW50L0xvd0xl
dmVsSW50ZXJwcmV0ZXIuYXNtCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9s
bGludC9Mb3dMZXZlbEludGVycHJldGVyLmFzbQkocmV2aXNpb24gMTg4OTAzKQorKysgU291cmNl
L0phdmFTY3JpcHRDb3JlL2xsaW50L0xvd0xldmVsSW50ZXJwcmV0ZXIuYXNtCSh3b3JraW5nIGNv
cHkpCkBAIC00MDEsMTEgKzQwMSwxMSBAQCBtYWNybyBjaGVja1N0YWNrUG9pbnRlckFsaWdubWVu
dCh0ZW1wUmVnCiAgICAgZW5kCiBlbmQKIAotaWYgQ19MT09QIG9yIEFSTTY0IG9yIFg4Nl82NCBv
ciBYODZfNjRfV0lOCitpZiBDX0xPT1Agb3IgQVJNNjQgb3IgWDg2XzY0X1dJTgogICAgIGNvbnN0
IENhbGxlZVNhdmVSZWdpc3RlckNvdW50ID0gMAogZWxzaWYgQVJNIG9yIEFSTXY3X1RSQURJVElP
TkFMIG9yIEFSTXY3CiAgICAgY29uc3QgQ2FsbGVlU2F2ZVJlZ2lzdGVyQ291bnQgPSA3Ci1lbHNp
ZiBTSDQgb3IgTUlQUworZWxzaWYgU0g0IG9yIE1JUFMgb3IgWDg2XzY0CiAgICAgY29uc3QgQ2Fs
bGVlU2F2ZVJlZ2lzdGVyQ291bnQgPSA1CiBlbHNpZiBYODYgb3IgWDg2X1dJTgogICAgIGNvbnN0
IENhbGxlZVNhdmVSZWdpc3RlckNvdW50ID0gMwpAQCAtNDE4LDcgKzQxOCw3IEBAIGNvbnN0IENh
bGxlZVJlZ2lzdGVyU2F2ZVNpemUgPSBDYWxsZWVTYXYKIGNvbnN0IFZNRW50cnlUb3RhbEZyYW1l
U2l6ZSA9IChDYWxsZWVSZWdpc3RlclNhdmVTaXplICsgc2l6ZW9mIFZNRW50cnlSZWNvcmQgKyBT
dGFja0FsaWdubWVudCAtIDEpICYgflN0YWNrQWxpZ25tZW50TWFzawogCiBtYWNybyBwdXNoQ2Fs
bGVlU2F2ZXMoKQotICAgIGlmIENfTE9PUCBvciBBUk02NCBvciBYODZfNjQgb3IgWDg2XzY0X1dJ
TgorICAgIGlmIENfTE9PUCBvciBBUk02NCBvciBYODZfNjRfV0lOCiAgICAgZWxzaWYgQVJNIG9y
IEFSTXY3X1RSQURJVElPTkFMCiAgICAgICAgIGVtaXQgInB1c2gge3I0LXIxMH0iCiAgICAgZWxz
aWYgQVJNdjcKQEAgLTQ0MCw2ICs0NDAsMTIgQEAgbWFjcm8gcHVzaENhbGxlZVNhdmVzKCkKICAg
ICAgICAgZW1pdCAicHVzaCAlZXNpIgogICAgICAgICBlbWl0ICJwdXNoICVlZGkiCiAgICAgICAg
IGVtaXQgInB1c2ggJWVieCIKKyAgICBlbHNpZiBYODZfNjQKKyAgICAgICAgZW1pdCAicHVzaCAl
cjE1IgorICAgICAgICBlbWl0ICJwdXNoICVyMTQiCisgICAgICAgIGVtaXQgInB1c2ggJXIxMyIK
KyAgICAgICAgZW1pdCAicHVzaCAlcjEyIgorICAgICAgICBlbWl0ICJwdXNoICVyYngiCiAgICAg
ZWxzaWYgWDg2X1dJTgogICAgICAgICBlbWl0ICJwdXNoIGVzaSIKICAgICAgICAgZW1pdCAicHVz
aCBlZGkiCkBAIC00NDgsNyArNDU0LDcgQEAgbWFjcm8gcHVzaENhbGxlZVNhdmVzKCkKIGVuZAog
CiBtYWNybyBwb3BDYWxsZWVTYXZlcygpCi0gICAgaWYgQ19MT09QIG9yIEFSTTY0IG9yIFg4Nl82
NCBvciBYODZfNjRfV0lOCisgICAgaWYgQ19MT09QIG9yIEFSTTY0IG9yIFg4Nl82NF9XSU4KICAg
ICBlbHNpZiBBUk0gb3IgQVJNdjdfVFJBRElUSU9OQUwKICAgICAgICAgZW1pdCAicG9wIHtyNC1y
MTB9IgogICAgIGVsc2lmIEFSTXY3CkBAIC00NzAsNiArNDc2LDEyIEBAIG1hY3JvIHBvcENhbGxl
ZVNhdmVzKCkKICAgICAgICAgZW1pdCAicG9wICVlYngiCiAgICAgICAgIGVtaXQgInBvcCAlZWRp
IgogICAgICAgICBlbWl0ICJwb3AgJWVzaSIKKyAgICBlbHNpZiBYODZfNjQKKyAgICAgICAgZW1p
dCAicG9wICVyYngiCisgICAgICAgIGVtaXQgInBvcCAlcjEyIgorICAgICAgICBlbWl0ICJwb3Ag
JXIxMyIKKyAgICAgICAgZW1pdCAicG9wICVyMTQiCisgICAgICAgIGVtaXQgInBvcCAlcjE1Igog
ICAgIGVsc2lmIFg4Nl9XSU4KICAgICAgICAgZW1pdCAicG9wIGVieCIKICAgICAgICAgZW1pdCAi
cG9wIGVkaSIK
</data>

          </attachment>
      

    </bug>

</bugzilla>