Closed Bug 576247 Opened 14 years ago Closed 13 years ago

TM: asm_stkarg not implemented for x86 [nanojit]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla7
Tracking Flags:
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: abittner, Assigned: m_kato)

References

(
URL
)

Details

(Keywords: 64bit, Whiteboard: [win64] fixed-in-nanojit)

Attachments

(4 files, 3 obsolete files)

screenshot of bad rendering comparison
72.97 KB, image/jpeg
Details
testcase errorneous rendering - 7zip archive
89.03 KB, application/octet-stream
Details
reftest
2.24 KB, patch
Details | Diff | Splinter Review
v3.1
5.30 KB, patch
edwsmith
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100630 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100630 Minefield/4.0b2pre

coming across a german website containing also the following html code:
<h1 class="head">Einfach stark in Preis und Leistung.</h1>

running everything on fresh win7x64 system, with having both native x64 and native x86 (via wow64) firefox4 installed

firefox 4.0b2pre compiled as x64/win64 renders the last part of that sentence "stark in Preis und Leistung." badly.

firefox 4.0b2pre as x86/win32 renders it properly.

when rightclicking on the html area of that text in the normal firefox gui it presents those text characters/words of the sentence as some internal png/base64 stuff (im not that familiar with the depths of firefox rendering engine and so forth).

copypaste-ing that png/base64representation via the clipboard actually reproduces the bad rendering on both of the 32bit and 64bit compiled firefox browsers.

so on the 64bit/x64 compiled binary of firefox there seems to be some rendering problem, or maybe the x64 specific parts of de-coding and rendering stuff badly create this png/base64 representation in the firefox memory cache for html content.

Reproducible: Always




here are the rightclick - view image url representations on the various firefox compilations:

x64 means: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100630 Minefield/4.0b2pre
running on freshly installed win7x64, latest updates



"Einfach" x64 representation: (renders properly (at least visually, didnt binary check the base64 part posted here below, on both x32/x64))

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGcAAAAdCAYAAAC3+HJeAAAExklEQVRoge2ZX4hVRRzHp7StTLMVMTaKiBVXektJqN3g7PzGe/bM75zrnd84IYqiDwWFFmRPhbH00D8IfZH+UGxEmxbURkQRpkYvRQRFSeXDtpVJUaEJVtuKbg/3nrtzZs/9f3fdrfOF38v8Zn7zm9/nzpm55zCWKVOmTJkyzQNx1A8D0gkI6WMe0Zr2xd14OyAdAaS/AOkfQDrGQ/U4Y+ySds1RSRCqpwBpNDbPmMUzPWdNcUkfCtSfVTOQdDDuD7jxDkCatOy7tuQRFtYB0t9O7ElAOtSO+LUESEP2vEGw5erZmLdWUn+kFMQx/WXcn0va7vgn1q69+7KW8wj1u07ccUAa55K2thq7rvn/C3DW5/PXOWNeaTUHY8wCQDprxfzJi6Llvfn8kiAILm81fj2aL3CGAOm5pOlH7DFe3qwEpD08VDs8z1vYag6+b5Y5ORxpNWajmhdwhDBL2z2HZ8zi9QH1ikj1pe2E24y5MgEnpMOVYhljFkBgbhaoBQ8U96JoeT05+L5ZxgPFIaJboyha5PorwclFerVALUCqVY2suS1qFI4QZqlAfSo2HtJw7OtD7IzbAel3yOevBaT9gDQxNYc6Y58jEOlCqb+9c87FcYwxHYwxBlKtAlQvAtJpp+95COkwDwrdafn6PnUB0gFAOmeN+ZOHNJzbsOEGqw4JOCJU2wDpuDPXm7N6i2sUjlcoXOOcR2/FvpTH0/cVzrGJ/gHTwxhjQuo7q513xpiOUoHPVusHSKe9vFlp55rLqRWAdKLKmB/inezCqWhS7ZsJDqmaBgdpr0D9RGyAapPdv0E4k8Wiqo8A1RmnfTdj9e8cjvoNyz8KqD+H4v+hqdylfiaxNklvO3FHhVTvl3byBR7qyKpDGpyvOdJXTtvJmSViL6DGbc1+bDHWGByB9El8JnBUxom9Px5Xuq1VPXN4UOgGSSMi0LeU2yJaA0jnrbFflH2SbnR8P/fm80sYY6x/wPQIpF1OHYaS6y6C8zxvISCNWb4Lnrf9itYrX4dmEg4gvRD7cpFenYiL+vnYVw+cKvnbhRsrt4f6/ko/hgpxEnDs2xogvWf7Zu3cmQZH0ohA/XpsINV9dv9m4RQP9Nbg+D51cVQP8pCGQdIIIB2C5FuFMhyBtNfZCTtr1KEanHfmBJw2XwjaBgdQbQLnjEmxMhyO6rXEukK1rUYdMjjNwMlF5iZnh4zzkIZLFxb7ojH1WJN00IFzV406ZHCagQNIu5N+tcXy2df1Mav9WSeXPTXqkMFpCo5UTyfGWn84K8ERSLuS86kPatRh7sMBVEeheNAmjAeKM3bRds5DDpyAMcaiKFoESL+kwekfMD1OLpM8VDtyObVCSNoMkj7tQ+y05pgPcNJNSNrM2EWCE+mCE/c3kDQCkn502scS46Z/hnBMvWTVIYPTDBxjTAdH+iY1tySgBBwvoOuh+GUzdU0c6dd498xNOFLtg2mfCKYbDwvrGCs/SmzfvXGsXG7rVbbPvr6WXoJOxbNefg4ODl6aiBnqB9w8fZ+6REgvA9JJgfoUhOpbgfoeHhS6AemAQPUqSHrMHdeH2AlIjwLSMeul7HGQ9KTvU1fcr/QRsZyD/RaAh3qn7Zutb0yZMmXKlClTpv+x/gVMovkCJf7PnQAAAABJRU5ErkJggg==

------------

"stark" x64 representation, badly rendered

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAE8AAAAdCAYAAADrcjF6AAAD8UlEQVRoge2Yz4scRRTH38aIko0kG5AgRiISjJeIsEaCGaG3Xu3MTr3q2alvTZPTggdZgiGiEBRF3fGQoB5El6jxFNCIBEX8cfHiwfjj5B8gC+4Sf0AQsgRJCCq4HpyZ9HR6ZrZnhskG+gN16O7XXa8+XfOqeohycnJycjYsyrrDLPi51Sr+wRud000DWzzPgrVWC7H/RueUiamZaC8LnmTBKRZ8P22qD42q75tenhb/anwAuowDo+o7lzcAG1peqRTtmC7joBavla0+Mjk5f2syZsTyxrSOtjUPNqQ8rlR2suAjFvzdlpzgirL4MIqiW4iIWLDMgquJmD+1+FW2+KTf/pWN7tbiV7X4VRZcCMNwCwteYsFFFqwpcceIOss7WKncwYKV5jOU4I9i6B8Yjp0uaB1tY8H5hJBYc+dasf8PrkMcviIimrY1ZuOeypJDcXb2nsSzvo0fq7BWJOosj8W/3HbeuteH6agjjTccT3yZDb5gwQoL1ti4I7HYnjNPiXtOW7yfJYcUeW2tXI7uJEqXVxCZYMGl2PmVMAy3DNdSB1j8Z7GO/wqiaGvz2tRMtDeoVrfH43vVPLb+LTbuzSw5pMi7yILjbHFIW9SvPft6ecpgoW2WWrg+VWRHiTsb6/xfLQ7NGpdGL3lK3Fm2eDZLDtfJ6yA/KU+FtWLbrLP+yyz9DgwLXkj5qfzKguPBTPXeZHzPmSfuHBtns+TQrzwt+Dx+PMoNOxERBdXqdhb81qHeXFEGT8Tje8vDUlCJ9mTJoV95LDjTNhMNFrIbGJBSCXexuA9SFoM1Fvyjxd/XjF2HvGUiGoufKxbnxrvtB/uXV3ss8eIvlUrRjgF19EdBZEJZd5it+ykxmNaK201eEEVbWfBx43CMiKhRl053G1Tf8kLsV4Kn2+/FiSHp6E3a4qCk9miboNiK11VeJdozJdVJIhoLgmCzNt6zwWvdFiCiweQFweO3s+D32PnLXKns7N9IBrTgKAt+0OLntZndx8bdz4K3E4X5aGsABifarhk3W6/XNxWLc+PKYPe08Q8HQbCZjTvC4l5ZTw6DyCMi0sY901b7xL8xHDtdqNfrm1iw1GGxuLZ9MbP7mvdo8fPJmsiCy9rgxaCMXWz9SSXuGFt8Ha+V3RhUXsrsuxqUsWs4ljqgQ1foIW6NBafi9zR29BdS4j7VAlGC75RgsSAysd48BpVHlDb78E7/ZtaJLuOAEixq8T/GP6xZ8I0ymKPEyklEpAx2s+A0G/zS+N5dUgYLWrxm60+y4Eyz9pXL5dsKIhPxlvx8aryQ91rN4lBarmzcTDwuvg8tFufGtfHvNq8pwWLav0I5OTk5OTkj5T8vukqH749NNQAAAABJRU5ErkJggg==

------------
"in"  - x64 representation (badly rendered)

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACsAAAAdCAYAAAAzfpVwAAABiElEQVRYhe3Vvy8EQRTA8XdBItFIFOgkLsSvxv0Ds/Mme3fz9tbOG9NIJHKFXnQkKpVQaCT+AIVErST+AJ1epxJRKRCnYJ2L+6Gxo9hv8po3zWeyu1mAvLy8vLzMEtqN+Tb8qlJpfUCRrft29CyouGmM+AyJrxTZByTeT88UmRlF9uFzfwsABY9UAKy6WSS7g8TPSNyQxEfpWUhmHokb6cjacujTClh1s5Ls9heoM/alXOZxn1YQsSsqMru9sJLMqU8nAACIJBnGyJ73wiqyKt0rYvKCl7XlEIkfe2Bv0l1AHCPxK5K5zNpawMgetnxEbbBKmw0AAKWXFpoX84HV5gCJ37pg78NwdUhUkgkkvmteLGOsc64Pibe6YiOzJ8TaIBJff38CmWNRmynUptLpNRCxK2Icj8qIT1qhHrABJaWgZuc6YWWNF6XmtZ9QD1hZTSY//mBtsQUkvkDip3+BRWNGOmGDyOr2SE9YIUR/uczjSHycjtK8AgCgyNa/79vMZqbYvLy8v+sd7voNp0VLKCAAAAAASUVORK5CYII=

------------

"Preis" x64 representation, badly rendered:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAE8AAAAdCAYAAADrcjF6AAAD7UlEQVRoge2YTYgcRRSA32bjz6IryBoNMYgiCCKBlU3UcUV66lUPdr2azrxXWwlZSYyXrAp6kWDIxVkMWQVBj3oQ9ORNCKLgLyKCl4B48KSugugpDPlBiJpkPez22NPMT8/s7OwK/UFduqpeVX39pqqmAQoKCgoKCvpBGflKkzubLorkG01yBo2c1iQUBMH2zZ7nlgRJziPJSo/yR5kk3uy5bjlyyltBkr/Rcmmz57ulaCPvdU3uVSR+F4kvpOsU8eejnFtg/M5Rjtc3WXlBcPTGZp3hMCP28szMsesGHSuKnrwFLZc0OR2a2nS3vTQ0temycQ8POtZI6CavXq9vQ5LL6fowjncBAKCVg5pcQ5NroHUfdhsjjONdSPIBklzJvIxz2rgT3vvxdHtl5Ki2UkeSc6vxZW5jVr9Ouslbq7/YUl+t3gYAoC0fST3/s1NGIvMUkvzSbT/VJG+09DGyoI070aw3Mr9xBtZBN3nlqnsgs9BL9Xp9G0CrPE3ubJf4b2VifIYkJ9HKt6lnVzXx/UkfZeSwsvLK/06eNjKviD2SnESS5UyGnEn6tWSekYV0zCCS3QAA3vvrkeRSSnIjiqIbAFYPAyS5mopxOum/9tI+7Uee9348tHM4PDM56OOq8g9WZV/SL5GnyTUqlcM3JQvQxh1H5ikAAB25BzMxvsyM/dt/dfx18znzVPqk7yUvCILtyvISxvEdw7XTg5zyLmrjDqT7NTPPyGvJM2V5KXiidnezDbFk4iwjydtJ0eQaqbpfm/2MO579NXRbg7K8VKn6e4ZnJSdt5C0jyc9I/ANa97Eifik5YdOsybuiq/4ugNVNvky1mdbY7qmcWb2CJOfXuo0hue/yytMkz4fG7R2qlLz0Om07oS0fSfZANBwqK5xto4w7lF8eXwAAmI3jSbTyBZJcayNvrCW+ddVNvcasRx6SlNHwfZrcsXZtVFSLWgT1uA8CAOhIHkHixQ6Z15Snzf49SPJcrkVuFIPKC01tuuT9hCb3bKc2QSS7Mxn2U3LVSZO+JId2DpXlZ7rIG5uN40k0/EK/ax06A2ceOa2NO9BORkt8I9+3Xnf4VMn7Ce/9uLZzgTb8iTLyctI+NG4vGlnoJA9JXtRG5vPOc0MZRF6lwrdrko9m43iyV9uc+95f2uzfAwCgotq9neQlf/OiyO9Y/8qHwCDykHgRjbyXdwxNfCp9ALQp15KfITJPdZKnjcwHxu/sle0jAw2/mb575flqgsSLyvLTfY1TlX1I/I4m+bH5QYHkdyR5X9HcowCrHyIAYEwZeTw9J2VrDwEAKOvvfIzo1ijyOwLvby55PzHQogsKCgoKCkbBv0XE6yEN2x6wAAAAAElFTkSuQmCC

-------------

"und" x64 representation, badly rendered

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAAAdCAYAAAAaeWr3AAACZ0lEQVRYhe2XsWsUQRTGV4mCQVIYLG0sxEZBrzFFZJ03Xph5s17mza0IZ1A02MQiaBWrAwUhRVpNI/4BRqwsLKyCIlZGLQVREURiIRqUELXY27u5vb1zRdjNkvngwbJv933zfjO7O+t5Tk5OTptIXNIdQHoTx1gY7ip6TLkKlHkISL/jCIJguOgx5SoHwAHYQgB83x/iwhypBuZgfK4QAExMCo7mSxyA+kw7J2nKznFpTrdzSLOde+j2v3gC1scB6YPV7HumzGVAepQ7AC51zTYFNOfiHJM0beeYpKl2E4rmrNxnIRojWfyqtdo+QPre7Zke5QGg6Gl2P3Mr0eg6Q1oGpLXyAkBzNqsfSHqXqHne8+KVoV+XEcCqtWPbxpS+CVLPpHm1lr89y2uVyqUdnZoFvAT/G4DS851areWtzJU0LxbQ0YTXip0vI4ANkPqA53keSD3TeSekAzip6tBVD2nZzpcOAEOzFB3rBiD9+hsAJjRLPAJP7HzpAADWx7msHQKkb101+gCAU+ZwAsCrrvzmAEAX49wgAEzScdB6FJDe9nzD+wCYmAj3ANKGde0P+5e3EACtXZn1XJolIcK9LKhXQdKLfgBO4GQFFN3raX4AgMiPnnfVVHQdtB5lkqZB0af8AUSz+DO1kUTEADia/akznwEAQ5rN4pUbgKghfaPPIB4D0tceAL27ucwAfN8fAqRnKfetA5oHhQCIIJgLDOll9HNjVgDpWhAEw4B0FZAWAWmRCzrWbDa3MzQL8bm04Gj4IC8hGiOA+i4gfQSkVUC6D0qP+WG4264ThuHOvPp3cnJy2nL6AwF2sayvKxqfAAAAAElFTkSuQmCC

------------

"Leistung." x64 representation, badly rendered

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAHUAAAAdCAYAAACUoyOLAAAGKUlEQVRoge2af4hUVRTH72Y/pDL7RYmRlpRF/qj80Q9X5c09d2Z999w3O/fcuVRKZhQmEZJkgkq4oPRnFBiy+KMiTY2CsqTCCinKHyyCBdkP+scV00gzEpPcnP6YebNv3u6bebMzs1syX7j/zH33nHPP57177nt3GGuqqaaaaqqppv534sreBEgfAdJRIc0613UvG+qYLmhxSbsFmi6BpotL2t0IHwL1W4CU8xtHvbQRfpoqCJBOBRJ+qiE+JO0PQgWkVwdsC7OzQNEyQP0mIO2rZ5wXjAYDqpDm+YCPHsDsrIHaAkV7ArbO1jPOC0aDAZUxxrgiLRR1JKWZVoudJtQYGiyocSQ8O0aorCPQCHDtXYyxlvA1/2WoSWmmcdQ2oYxMeGaCEHbkkAQyOMuvXiLQnPQbdzUP9ielmQZIX4bqbg6QjoGiZYwxlvDMBIHmJCCdC15TtCv1EsYY45idUeJL6UW+H66MF+wTaBYW+yQtKI5Bvb2a+YFH0wHNN/3EnwOk075dUGZtbZmMG9BgbJSQVoRAtPl9XGXuA6SzEQnJcUWrGWMM0mZy1DWFtoIxxrik2aU7bXrW9yWkMSVjpF5cjFHSU719+o9kOj06ztySytwOSKcrxJaft6RN9ctqGdUKNX/36zVJmbmnjI9oqKg/DU1+HyDtAqTfACmXQj2RsSqe1LpApR/i509vDMXfyZVeBEivlfyuzNpBW45rgSo8OwaQzheSd6iMj0iogPR7oO/rwLAW8Gh6H1sVampdoAZ+ryRA+jEwr66S+JG6A1BfiWuzZtUCFRRlg0lKpR69IsJHOajHAn3dwjX3VvDZaKhn2trstQF/yzmalZHxSDrcOy96P9R3MODvw3LzqqtqgZryzJ0CzUK/eZ53eYSPSKhC6k/61B9FB0Dqxa3p9Ig+thoNVdH64vWKOiBQ1yPm9nGvPTrs39ig9XWA9Geg7404Oa2Laq2pMX2UqanZGRC9UeoWLj1QYqvRUAtLPig9r1haykDlinQo5iMCTRdH+jXw2/mkykKteYytGqH2eY+M8BEJlTHGEtLcD4o+85MYaj93dHRcVLTVWKifM8aYQNMGSH8XbZSBmp+ffj3ipswBUg8oWh4nT3XTQKG2ptMjuJtxY/ooC9WXQDOOS1oFpZunnJDtk4q2Ggg1gZQWaMYVdtm5OFCFbJ8UWGZPgKL1As3bgLSBo14KUo+Pk6O6qgqoxafSWnupQNop0IiYPiKhWmuH9ble0fLQ3Z4I9FUJtfdEqBzUpEutjrVXcqRvw09b2ZoqaVvxWkXvxMkHY4w5aXsbIG0VSDuF0vPjjoulENRzkH9HLG355cOH2iIkbQJFe1gdll+OejtHvR0UPQRSj08ofTeg/qIksWkzOWDrq+DS5nje9Y6zYLjjOBczxlgK9cQQlF2plL4h//mR9kZBTWBmKiBt6G8JLb9RKvmS1AOSDvpHmYC0S0izDqROBsdYa4cJpJ9KfMRc9WIpBLXfxhVtYQWAAvUaQOrmksZW4aNfqFzSWEDqqeD/mA+MMca4oi2h/r8A6ax/8uM4C4ZDcNdZrhWgQjp9YzjJ8aHS1ni+aIf/5wBnTuaWPj7QvDQggBFBxYXKuNKLQNI2R9pRARMtjrSjuEdTuDIel+YRkDo5E/GailDRrKzg+x9Qel4wXuHpmRD6qgSh2glIz0Ukdj8gHe0DVdKLFeYfCTXV3n4zKDoeByxX+nHGGJs6deEl4TFC0ty6AM1PSL8MSJ0V2hNC2JFC6nbu0RSBpg2kVhy1FUrP55JmJ+bYO6I+PnA345bYy5/AMGvtsMIrwWZQ+vvih2+kI4DmvaRLrf3ZE56eKZB2gqLjhTFdQhpTMi/UD4OiAwV733FFq1133lWFT3idgNTpHywUoEbOX0jdXiF/BTjmMY7actSWS3oyVP9zgHpjcZzSDwLSPo50iEtaxWKWsqYarPzpTBHa0XB/yrO3hp7WrUMRZ1NVSEiaG6ztobLEuDLPhKC+MFSxNhVTyXR6dGhTdgok7eBo3u3nfPWM8OyYoY65qRgSaAQg/VJhk3QCpFZDHWtTVcjJZK4GpKdBmQ9A0Z78eyrtBUnbQOrFwVOfRupfeCzTic4Uc/sAAAAASUVORK5CYII=

-------------


try copy/pasting these data: urls into your address location area and see the bad image rendering on a normally working win32/x86 firefox4.0b2pre

------------------
additional update on a x32/x86 firefox4.0b2pre

x32 means: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100630 Minefield/4.0b2pre

running on the very same machine, win7x64 fresh, latest updates.

all data urls are being displayed fine visually, just for reference/comparison to the x64 data: urls posted before

"Einfach" x32 representation

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGcAAAAdCAYAAAC3+HJeAAAExklEQVRoge2ZX4hVRRzHp7StTLMVMTaKiBVXektJqN3g7PzGe/bM75zrnd84IYqiDwWFFmRPhbH00D8IfZH+UGxEmxbURkQRpkYvRQRFSeXDtpVJUaEJVtuKbg/3nrtzZs/9f3fdrfOF38v8Zn7zm9/nzpm55zCWKVOmTJkyzQNx1A8D0gkI6WMe0Zr2xd14OyAdAaS/AOkfQDrGQ/U4Y+ySds1RSRCqpwBpNDbPmMUzPWdNcUkfCtSfVTOQdDDuD7jxDkCatOy7tuQRFtYB0t9O7ElAOtSO+LUESEP2vEGw5erZmLdWUn+kFMQx/WXcn0va7vgn1q69+7KW8wj1u07ccUAa55K2thq7rvn/C3DW5/PXOWNeaTUHY8wCQDprxfzJi6Llvfn8kiAILm81fj2aL3CGAOm5pOlH7DFe3qwEpD08VDs8z1vYag6+b5Y5ORxpNWajmhdwhDBL2z2HZ8zi9QH1ikj1pe2E24y5MgEnpMOVYhljFkBgbhaoBQ8U96JoeT05+L5ZxgPFIaJboyha5PorwclFerVALUCqVY2suS1qFI4QZqlAfSo2HtJw7OtD7IzbAel3yOevBaT9gDQxNYc6Y58jEOlCqb+9c87FcYwxHYwxBlKtAlQvAtJpp+95COkwDwrdafn6PnUB0gFAOmeN+ZOHNJzbsOEGqw4JOCJU2wDpuDPXm7N6i2sUjlcoXOOcR2/FvpTH0/cVzrGJ/gHTwxhjQuo7q513xpiOUoHPVusHSKe9vFlp55rLqRWAdKLKmB/inezCqWhS7ZsJDqmaBgdpr0D9RGyAapPdv0E4k8Wiqo8A1RmnfTdj9e8cjvoNyz8KqD+H4v+hqdylfiaxNklvO3FHhVTvl3byBR7qyKpDGpyvOdJXTtvJmSViL6DGbc1+bDHWGByB9El8JnBUxom9Px5Xuq1VPXN4UOgGSSMi0LeU2yJaA0jnrbFflH2SbnR8P/fm80sYY6x/wPQIpF1OHYaS6y6C8zxvISCNWb4Lnrf9itYrX4dmEg4gvRD7cpFenYiL+vnYVw+cKvnbhRsrt4f6/ko/hgpxEnDs2xogvWf7Zu3cmQZH0ohA/XpsINV9dv9m4RQP9Nbg+D51cVQP8pCGQdIIIB2C5FuFMhyBtNfZCTtr1KEanHfmBJw2XwjaBgdQbQLnjEmxMhyO6rXEukK1rUYdMjjNwMlF5iZnh4zzkIZLFxb7ojH1WJN00IFzV406ZHCagQNIu5N+tcXy2df1Mav9WSeXPTXqkMFpCo5UTyfGWn84K8ERSLuS86kPatRh7sMBVEeheNAmjAeKM3bRds5DDpyAMcaiKFoESL+kwekfMD1OLpM8VDtyObVCSNoMkj7tQ+y05pgPcNJNSNrM2EWCE+mCE/c3kDQCkn502scS46Z/hnBMvWTVIYPTDBxjTAdH+iY1tySgBBwvoOuh+GUzdU0c6dd498xNOFLtg2mfCKYbDwvrGCs/SmzfvXGsXG7rVbbPvr6WXoJOxbNefg4ODl6aiBnqB9w8fZ+6REgvA9JJgfoUhOpbgfoeHhS6AemAQPUqSHrMHdeH2AlIjwLSMeul7HGQ9KTvU1fcr/QRsZyD/RaAh3qn7Zutb0yZMmXKlClTpv+x/gVMovkCJf7PnQAAAABJRU5ErkJggg==

-------------

"stark" as x32 representation:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAE8AAAAdCAYAAADrcjF6AAAEGklEQVRoge2YTYgcRRTHK1FBEs0XSPzE6MGYQ5bAGglmhd56tTM79bp7p/41TQ5hwUNYohJQ8BIxZhASRVAkoMZTEA1LRPyIFyEnI3oQD5KTBsxiNLoIWYLuEhOXjIeZbms6PTO77MxkA/2HOnS9V1+/fvNe9QiRK1euXLmWraRv9hLj56SFduBG7+mmEfnYT4xa0gJsv9F7WpSGR6PNxHiGGEeJ8c2ILm/r19o3PTzF9jX3AKqEHf1aO4e3BC1reMVitGGkhJ2KrZJ++fHBwYnb0j6Lged53q0U2gHFVim/4ikVrV3klla4Y5YlPArDjcSYJMbVps0x5qSP41EU3SKEEMQ4R4zLKZ+/FNsZ8vFxPN+ILm8jxofE+DvlO08aJ0fC8F53felH9ym2M4rtDDGmgyBYRYwDxLhIjJpk84IQreHtDMM7iTEVzyEZfxYC+2jPwSkVrSXGL6lDOs2cTnzrh2vhhy/rPmYLMa608asR43dPR3fH8xbGxh5I2b92n2VQKbSDR2xfbur3zes9B1dfGAdSGz9HGieJMUWMGmnzrOO7oMgjNqcd+0/E+CED6Ctt4DW1Uim6qxW8Ieb1xLjk9E8FQbCqT/DsZ87CV7wouiO2DY9Gm71yeZ3rv5CcN8zlQWJMKjZbknW0GUlBORXbMuBdJMYh8rFL+agmc2TAkxoHm6LUh+k6pFaSbE44i19TbBDnuCwtpdoSYzYZq/Fd3H8dPG3eyhyfgieDSqEp6nz7xeJOv0QR48WMn8qvxDjkjZY3pf0XCs8bLW9qHHZSMT4nxilizHcTXmPe5LmfF3YhhBBeubyOGL+1yDdzUmOP678QeIrt03R95W5uXYBH9Yr+fyRqHOw+oQ4qFnEPsfkgoxjUiPGvYvtw7NsJXuOaMu/4zBHjWGPc1e7CqzyZevGXisVoQ+9ItdEQ83rpm73kmx9Th0kqbid40jevpvNSbGuA7B68ANsl47lURB/uBZtMZRUHyZUnmgA5Fa8TPNJ437WXSrvXJLYewPO8p24nxgWnf5bCcGNX4HSSYuwjxreK7YTSY1tJm0eI8XYqMe9LDqBxuMmmzVi1Wl1ZKIyvrtvNG81J3D4mRJJb/+k2PCGEUNo83xTtbN/sLTUhRLVaXUmMs20TO+Oa0mNb4zGK7UQ6JxJjVmm8JIQQUmNPyn6BND4lxh9dLxgNeBnRd9kr4f6ewlOBGeoArkaMo+6Yxo1+OsPvEyGEKJV2r6FW1VvjfC/gCZEVfXinV9wSqRJ2SMYRxfZ798OaGF9JjXEhxIr0GKnxIDGOkcb5xvfuWfeaUAiihxTbj4gxXbfbM1JjnEI7INmckD6Ok4/9sX/jhbyXNB+7svZK2oy6fu49tFAYX620fTe2ScaRrH+FcuXKlStXrr7qP1Dl7/MYDyHyAAAAAElFTkSuQmCC

---------------

"in" as x32 representation:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACsAAAAdCAYAAAAzfpVwAAABOklEQVRYhe2UMUvEMBTHozgKLiLorqKIs5u9vLTn9aWF/GMV/RLuOlgcRRwFd7+Cm+Di99BBBxfRTQc5l0ttD6qLd62QH7wh+RPye/ASITyef0ie55OS7TkxniSbm1DbxaadaiGNXWL0XUnGXdNOtRDjsCxLjMemnWqJ2KwR46OQ1ea0aacfodSuyxjHKrY7QoiJpn3+FKWymTAxm6qHjSAIpsZ2cWcrW1ZsX1wR46yQYrNS2r8PkmSWGFfE+PweGzwrBo9FlnrZ6tBvcOGywTyXH9/D0HpQ5i2KzFzbZPvEeCU2t8R4r5yL7V6rZBXjOsiyaSGEIG0PqufsUatkiXHiMtkzstKIRt5aWaW3Ay/rZb2sl/Wyv9PtYp4Yl65UjH2XhWm6UM46jLRoMjZL5Uxqm4xc1uPxjIYvuqGDB8xj3JAAAAAASUVORK5CYII=

------------------

"Preis" as x32 representation:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAE8AAAAdCAYAAADrcjF6AAAEAUlEQVRoge2YTYgcRRTHy8RoxI+D5iAhd78SiQwbXAObnn5vNna97snUqy0lMWpAWBHBi0hCLo6wBA+CHhTiQQx4WPCgLCFBMYiI4CVBBBMP6iqIJgFdko3BmJgdD7vdU10z09PL2K2H/sM7TL+q9179uvtV9QhRqVKlSpX+F/KiaANI/hCIzwKpI54xt/3XNfWVL/kzJH3SNp/4CySeA8mHkJg8z7uxzJog1G8CcScxyYfKzJ9bQHwhVWh/+7VO3Cyxpo+c/LNl5V6VcsLrAPFVCNV4STU9Y+VdKvPGrUp94L2GpF8FUkeA1EXb55M6UVZdftAKgNQrjYC3l5Vz1XLhed6+9YlPqoYD9kqtNr0uK16tNr1ucvLJW/v5guCJOyBU40gaG7K1ddRe2mg2N/qSJ5A0oty1pd1urxkl3qqVBa/dbq8B4iu2v9FsbhRCCAj5cSS9gKQXINRHQam7gNR7QPwnEHfq1KrZiwTiD4D4b+dm/IZSHzDGrLVr8iXvi2Mvx+epVM2Bud8ndQKIl5x4vyOpmaKZdQvJgLfiX0z5o2iDEEJgqJ6yrl8G4lPW72txnGWo/GNWP0Xi11M5JT+b8kveE/smI30vEP+REe+tMrjFcAbCq0f6AaewS/Gr4cBz7Rsr/mHH9wkQH4SQv7SuXUdS9yVzMuAh6ffT8fRXK7vzOSDu+JInymLXAw8l7/FJGSA+CMTzzhMylyyiF94ZIH7Rl3o3kp4WQghjzE1AfKk7Xy8EQXCzEEJ40twNxNeT+dZZLgseEP/Q3cD4W7vPQcRjpfY9F16GXYOIx+J5PfAi3XJjY6AfcmJ86uT+uetTnyfXs+GdsXumT1OPFMVmqHLCW0SpH7Pn5YJHip0480D8dmxIesHy/ZTUlA1vtl+bQKlf2rnT3FkoLFd94M0vvxrqNIT6uE9qf7zD2soDD0g/nfOp7gDxhWRe1oZBajMM2jBCPo+ksThaPQvM3m0HKQ88X+rd+eGpi0lNGfCEEAKa+kEI9fFUz+zaubxrGFmFwgtaQfrJ0Edz1TQEXiwv4E0o9QEI+bw9vhGpHXnyjKwi4XkBb3Keiu/77YbuITkLnju2/3it861+RBUJTwghQPLXqYWRmhk35hZjzFoMpzyU6mNf8svOnKwN4zASzwHpvfVHzT2TpDYj8bHU+HDKGwlKXhUNL2ff+wvlri1JTQPgrXytXB4Sa3F7s3n7v0NniIqGJ4QQSGoGer9DbVsCqV5IahoAD0k/N/RGSPX86FRyCqR6A6yz17B/TWJhwA/b8xqytTUzT8RjQOodJP4u+eAn/gWIZ92Dri95wo7th61tK64b6qGWQPwukDptxTmLxMdKPaZUqlSpUqVKw/QPlGDkXxeFCJMAAAAASUVORK5CYII=

---------------------

"und" as x32 representation:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAAAdCAYAAAAaeWr3AAACQ0lEQVRYhe2XvWsUQRjGR4iCIVgYLDV2WgX0CJhC2Mw7Xm733cndPHMjggRFg5VFQBvTaivY6TXiP6BYCYpYBT/QxqilICqCiBaiQQl+FOfezS6nWCS7udw+8DbzzLwfv9s5doUoVapUqXUkFeEqMV4mMenc1qJ7ylUU21vE+JWE1nq46J5yVQmgBLABAMgIY4qtmqq5Pf/aFwTBkArtvqq2e5O1QgDIsBEqtp+SIDZHOl6EWd9TkT3c8Rjz3TO4QhoTiu0TfwCK8UBGGMvWJG4eJMZbb+8bGdvTxLiTOwAVmXqqabbHPABzvicjzHaGiHHO8z4Q40s6TztUZG779ar1+k5ifO21Nxv9BCCJV4rxMLP2M3BupFvPXs74K5KxSIzlvgYg2ZwVQmwSQgjJ5m4q54wd75yL8DqT87gQyZNhXvQtANKY6A5pLvneFDcq3SFTv/JypXJqczdnAX+CawTgYi8AUmN/ptaS38uGB3AoblL62mBxoADI0MjMFbg/UABoxo5nADxfhwBwcq0ATE+77cT44Xnf/E/eQgD8eSvz7qW9HoZuh9TNKkV4upoA2vXwOJUzxnkyZlRGmKMY7/MHYMwoMb5nnoKesRoAJGP+f2rlBkAIIRSbC39p4h4xPq8mgCAIhojxqEetFWJ7sxAAbQj2hGQ8a3/c2CViLGith4lxhhgtYrRUiAPekLVknRitoNbYnXiSjfM9pd0uv1YYHt1GbK4R4x0xPhLjBsVmMnBuxD/nnNuSG4BSpUqVGjT9BoifBvTAnrchAAAAAElFTkSuQmCC

--------------

"Leistung." as x32 representation:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAHUAAAAdCAYAAACUoyOLAAAGNUlEQVRoge1aaYwURRQuDgOJ8UJjjAgKUYJyGAU8OExvvZpZu1717tar6WggKkaCRJGIIgkgsgn+NppAyEZRURAQTRAlatCEiMqRDYo/xGgUBcTFCGJEQVlYf8z0THXP2buzh2S+pP706/feV++rqaNrGKuhhhpqqKGGGv534MofCkjvA9IRIc0q13UH9Tan8xpc0naBplWgaeWStndHDoH6DUDqCBpHvaA78tSQASCdsAp+oltySNpjiwpIKzsdC1PTQNFCQP06IO2uJs/zBj0hqpDmKStHO2BqWmdjgaKdVqzT1eR53qAnRGWMMa5IC0XNCWkmdiVOTdQK0BVRpyJexjE1OaFSIGTjuObm5v5d4SI8f7hQKUegEeD6NzHG+uXx7WFRufKHJlQKkqjHlns3Ic1EjtqvU0bWeWaMEP4l3c2vIDojqkAzMrObPRtZK9u4MnNZRAwh9XyB5njQuKu5bU9IMxGQdkRidQBSGyhayBhjdZ4ZI9AcB6Qz9jvZuFLPZ4wxjqnJoVxKzwnycGU82ybQzM7aJM3M+qDemEQ9liN9GuHzZdIzo/Nq6NEkQPNVAf4dgHQyiAvKrIglTmcRV9RkY+MwQGor0oGgLY3kWBwRoj6wcdV0GyCdLhaLK1rOGGPQYMaXybmYMca4pLvCO216PMglpDEhH6nnZTlKejhn039kBlB+Hkl7mDVoE8rcAEgny3BL91vSy10Sq1LEFRWQNkU6uYWjWQJovrCe/+O4dI3lU1xU1B9FOr8bkLYB0m+A1BFMexX/Uqsiarb9XODX2iE8f3iub3p1xN7ClZ4DSK+Eniuzosem4zii1tf7QwDpX+v9n1hm1CY9MzpczNxZtJSogPS7ZfvcStcPPJqUx7fMmlotUQXqZ4M9gkDzZsimUo7F/1urX60h/kiHLFFfKFXbqiKOqAKNiIzKTZFY1jRkNlvPS4lqT+WHhGtuKcm3x0S1OZpnIn4Jy+9gzofeCXGVtM/ye69Uv6qKOKJySbMiBdsPSC1W+ys3MmmvlaOoqELqD/OmPUV7Qep5UxoaLsrj2wuiCklPFxUV6YPcczqYTN53IWOMgdaXA9Kflm1NZYpUAXFEBWWeyBOgePvBylFiTU1NhuIbpUPCpTvCHPqWqFyRjnA+LNC0cqRfrWfnEioFcXTpEmL9UpWZG0PUA1aOoqIyxlidNLeDoo8B6VyBON/b59++Jmq6f/rVEnVoB0WLKtWjKoj3S9Uzwp2rbEopJ2oAgWYkl7QMwpunDiEbx+U49C1RhWwcZ02zx0DRi5mN1Usc9QKQelQlNaoqYokaOStGdnsB+rHIx4dSovq+PyAvj6JFkdFeZ9liiprbhXfLmippQ/a5ordK1c+G0+BfD0jrBdJWofT9lfpVhIioZyB9Rgy3zPTR3NzcH5B+jBbNdd1BjuMMFGjqAWmHQHoskqPUOXUjR70RFN0DUo+qU/pmQP1JqIgNZrwV6zN7anM87wrHmTnYcZyBjDGWRD02MiC2JZP6yvTnR9pVdVHDX5LaQdK+4CoTkLYJaVZFp2vf9wcIpO9CdXSb3O4StWDjitblOq8fLfc+IJ1Mev6IcqJySdcCUnuZWG2BYIwxxhWti9hPAdLp4ObHcWYOBnvXWapVZ/e7vrJctCX4c4Bzd9N1eTVG81yvicrSh+qVZXzO2lNKUVHRLCkXB5SeYfMVnp4Kka9K6aLk1k5AerJIYfcA0pFqippsbBwGio5WIixX+kHGGJswYfYFUR8haXr1RJX6eQifNQu1h/L8MDVNKHoNkA5kP1hLOgiS1nCPbrXf5W6TG4qXvoFhvu8PyBwJ1oLS32TjIB0GNJsTLk0pxFl4eqpA2gqKjmZ8WoU0JsxP3wuK9mbifc0VLXfdGRdnPuG1AFKLfbGQWYvzODLGWJ0y0rYJ1DdG6pcRxzzAUfsctc8lzYqs/x2AenXWT+k7AWk3R9rPJS1jBW6kaugFpG9nsqIdidqTnj8i8mtd3xs8a4gBIWm6JdgpR/pX2fYC5/qlxWLV0EeQaGi4GsKbshOZW6u3C9yv/m3f7tTQh5G55PilzCbpGEiteptrDTHgNDVdCkiPgDLvgqKd6XMq7QJJG0DqefX1/pCe4PEfVmrZ4QtpHPAAAAAASUVORK5CYII=

---------------------




conclusion:

only the first word "Einfach" gets the same encoding/decoding in both the x64 and x32 versions of firefox, the rest of the words encode/decode differently.


maybe this is some hint for where to look for the reason.

regards.
x32 firefox renders normally, x64 firefox renders badly.

but copy/paste the data: url representation of the badly rendered stuff from x64 firefox over to x32 firefox gives bad rendering on x32 firefox as well.

so some decode/encode curriuption, memory corruption or something must be happening on the x64 firefox.

cheers.
the opposite direction holds true as well: 

pasting the x32 data: representations back into the native x64 firefox renders the images/words correctly there as well.
bug still in:

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100701 Minefield/4.0b2pre

about:buildconfig
Source

Built from http://hg.mozilla.org/mozilla-central/rev/d9253109fd88
Build platform
target
x86_64-pc-mingw32
Build tools
Compiler 	Version 	Compiler flags
cl 	16.00.30319.01 	-TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
cl 	16.00.30319.01 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -wd4800 -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
Configure arguments

--target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32 --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-debug-symbols

---------------
regards.
still the same buggage with newer x64 compiled build

Build identifier: Mozilla/5.0 (Windows; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100703 Minefield/4.0b2pre

-----------
about:buildconfig
Source

Built from http://hg.mozilla.org/mozilla-central/rev/55f39d8d866c
Build platform
target
x86_64-pc-mingw32
Build tools
Compiler 	Version 	Compiler flags
cl 	16.00.30319.01 	-TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
cl 	16.00.30319.01 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -wd4800 -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
Configure arguments

--target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32 --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-debug-symbols

---------------------

same display errors on the mentioned url.
Hardware: x86 → x86_64
any comments on this stuff? is x64 for mozilla still too exotic and low-prio?

do we have an x64 discussion area, meeting place, weekly/regular meetings or anything?

win64/x64 is huge by now if you trust microsofts own word and published stats. almost half of all total sold win7 licenses were x64 up til now. in the us the current percentage is even around 60%+ for x64.

well whatever. maybe some body cares or could explain how these differences occur and where this stuff originates from.

cheers.

ref: http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/07/08/64-bit-momentum-surges-with-windows-7.aspx
Version: unspecified → Trunk
I have verified that:
1) the win64 build on a 64-bit machines renders incorrectly as per screen-shot
2) the win32 build renders it properly

I don't know which component should this belong to but the fonts are not being rendered properly.

This is a very obvious regression and would not like us to ship with a problem like this. Thanks abbittner for filing. My apologies for the late reply we were at a summit all last week .

abittner could you keep a saved version of the page? could you please get us information wrt the fonts that are being used on that page?

(In reply to comment #6)
> any comments on this stuff? is x64 for mozilla still too exotic and low-prio?
> 
It is not low-priority but it requires a lot of changes in how we do things. For instance, I am not sure how many developers are actually running the 64-bit builds and how many nightly users we actually have.
I (most likely) will be leading the push to get it into our beta releases (maybe beta 3).

> do we have an x64 discussion area, meeting place, weekly/regular meetings or
> anything?
> 
Best place to ask is http://groups.google.com/group/mozilla.dev.planning
I am not sure since I am neither QA nor developer so I am not the best person to answer your questions.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: 64bit
Whiteboard: [win64]
tried to narrow down the html/javascript code to be still able to experience the bug. some javascript stuff (third party mit/bsd licensed) is neccessary, which creates fonts and stylesheet information via javascript it seems. im not that of an expert that deep into javascript, stylesheets and font technology.

see 7zip archive. html file with six .js files recreates the bug.

extract to any directory and start the html file via your x64 firefox browser and/or x32 browser to compare results.
update on builds:

Build identifier: Mozilla/5.0 (Windows; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100714 Minefield/4.0b2pre

about:buildconfig
Source

Built from http://hg.mozilla.org/mozilla-central/rev/c26c255bade9
Build platform
target
x86_64-pc-mingw32
Build tools
Compiler 	Version 	Compiler flags
cl 	16.00.30319.01 	-TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
cl 	16.00.30319.01 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -wd4800 -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
Configure arguments

--target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32 --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-debug-symbols

------------

still experiences the malfully rendered situation on x64/win64 native.

was just posting for the records, as i think i recently read somewhere that somebody from the x64 team, buildengineering or whoever was experimenting with compiling x64 either with visualc++2008/2010, so that might give some hints what libraries or parts get compiled in some strange way that the font/js/css parts create the bad font representation at some point.

regards.
ok, so here goes the next x64 stuff, maybe its related, maybe i need to open a completely new bugreport.


i can 100% repro an immediate non-crashreporter crash with simply navigating to html5test.com

on this latest x64 firefox that i am testing.
Build identifier: Mozilla/5.0 (Windows; Windows NT 6.1; Win64; x64; en-US;
rv:2.0b2pre) Gecko/20100714 Minefield/4.0b2pre



its not reporting anything back to mozilla, bug creating hugeloads of wer (windows error reporting) crashreports sending back to msft.

crashing module is xul.dll each and every time.

can anyone else repro this?
target crashtriggering addy is: http://html5test.com/

doesnt crash but computes some html5 capability score x32 firefox builds for me.

on x64 it gives me the crashy.

i call for somebody taking the wer (windows error reporting) stuff seriously and making use of wer-reported crashes and go for registering with microsoft and adding wer-capability to the major mozilla products and learning from the wer-reports as well and not just the breakpad/crashreporter reports.

thanks and regards.

--------------------

Description
Faulting Application Path:	C:\Program Files (x86)\Minefield\firefox.exe

Problem signature
Problem Event Name:	APPCRASH
Application Name:	firefox.exe
Application Version:	2.0.0.3846
Application Timestamp:	4c3dca57
Fault Module Name:	xul.dll
Fault Module Version:	2.0.0.3846
Fault Module Timestamp:	4c3dc993
Exception Code:	c0000005
Exception Offset:	0000000000276928
OS Version:	6.1.7601.2.1.0.256.1
Locale ID:	1033
Additional Information 1:	25c0
Additional Information 2:	25c09b994a48fea9e9d21b3b8db14eb6
Additional Information 3:	613f
Additional Information 4:	613f902109b04e71c13aa2112ec8251b

Extra information about the problem
Bucket ID:	19070399

--------

Description
Faulting Application Path:	C:\Program Files (x86)\Minefield\firefox.exe

Problem signature
Problem Event Name:	APPCRASH
Application Name:	firefox.exe
Application Version:	2.0.0.3846
Application Timestamp:	4c3dca57
Fault Module Name:	xul.dll
Fault Module Version:	2.0.0.3846
Fault Module Timestamp:	4c3dc993
Exception Code:	c0000005
Exception Offset:	0000000000276928
OS Version:	6.1.7601.2.1.0.256.1
Locale ID:	1033
Additional Information 1:	25c0
Additional Information 2:	25c09b994a48fea9e9d21b3b8db14eb6
Additional Information 3:	613f
Additional Information 4:	613f902109b04e71c13aa2112ec8251b

Extra information about the problem
Bucket ID:	19070399

---------------

Description
Faulting Application Path:	C:\Program Files (x86)\Minefield\firefox.exe

Problem signature
Problem Event Name:	APPCRASH
Application Name:	firefox.exe
Application Version:	2.0.0.3846
Application Timestamp:	4c3dca57
Fault Module Name:	xul.dll
Fault Module Version:	2.0.0.3846
Fault Module Timestamp:	4c3dc993
Exception Code:	c0000005
Exception Offset:	0000000000276928
OS Version:	6.1.7601.2.1.0.256.1
Locale ID:	1033
Additional Information 1:	25c0
Additional Information 2:	25c09b994a48fea9e9d21b3b8db14eb6
Additional Information 3:	613f
Additional Information 4:	613f902109b04e71c13aa2112ec8251b

Extra information about the problem
Bucket ID:	19070399

-------------------

Description
Faulting Application Path:	C:\Program Files (x86)\Minefield\firefox.exe

Problem signature
Problem Event Name:	APPCRASH
Application Name:	firefox.exe
Application Version:	2.0.0.3846
Application Timestamp:	4c3dca57
Fault Module Name:	xul.dll
Fault Module Version:	2.0.0.3846
Fault Module Timestamp:	4c3dc993
Exception Code:	c0000005
Exception Offset:	0000000000276928
OS Version:	6.1.7601.2.1.0.256.1
Locale ID:	1033
Additional Information 1:	25c0
Additional Information 2:	25c09b994a48fea9e9d21b3b8db14eb6
Additional Information 3:	613f
Additional Information 4:	613f902109b04e71c13aa2112ec8251b

Extra information about the problem
Bucket ID:	19070399

---------------

greetings.
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg and please don't use a bug about "error in rendering" to describe "it crashes", use a new bug (they're cheap).
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
This goes away when the jit is turned off. I guess it will need further minimization.
I've reproduced this just using cufon at:

http://people.mozilla.org/~jmuizelaar/cufon-test/test.html
Summary: x64/win64 build of firefox4.0b2pre display error in rendering html text (created as internal png representation) text → cufon gives corrupted text on x64 with jit
Since bezierCurveTo has a lot of float parameters, I have to implement asm_stkarg for double type...
Assignee: general → m_kato
Summary: cufon gives corrupted text on x64 with jit → TM: cufon gives corrupted text on x64 with jit [nanojit]
Summary: TM: cufon gives corrupted text on x64 with jit [nanojit] → TM: asm_stkarg not implemented for x86 [nanojit]
OS: Windows 7 → All
Attached patch fix (obsolete) — — Splinter Review 

    
  

        Attachment #459735 -
        Flags: review?(edwsmith)

    
    

    
  
Comment on attachment 459735 [details] [diff] [review]
fix

Nice catch!  Did the TODO assert fire when testing?

The encoding of MOVQSPX doesn't incorporate the REX.W byte, and so will fail if r == XMM8-XMM15.  The current encoding in the patch is:

   00 24 44 D6 0F 66 00 06LL
                 ^
This is where REX.W belongs.  In the single-quadword encoding, it should be 40 (hex) 

Where does the byte D6 come from?  In looking at the X64 manual, the encoding of MOVQ r/m64 <- xmm is:  66 REX.W 0F 7E /r, which would lead to an instruction word like this:

   0x 00 24 44 7E 0F 40 66 07 LL => 0x0024447E0F406607

In the existing code (before the patch), the comment on X64_movspr is incorrect,
it should read:

   // 64bit store gpr -> [rsp+d8] (sib required)
                               ^

Notice how in MOVQSPR, we use U64(d)<<56 and thus only use the low 8 bits of the offset.  This will be fine in asm_stkarg() as long as stk_off is a signed 8-bit value, which is ensured by an assert.  

To land this, I recommend:

1. fix the X64_movqspx constant as above: add REX.W, fix the opcode byte (D6 should be 7E), update the length byte from 06 to 07, and fix the comment.  If D6 is the correct opcode value, please explain.

2. Also please fix the comment on X64_movspr (replace "d32" with "d8")

3. Update the shift expressions in MOVQSPX() to correspond to the correct bit offsets in X64_movqspx.  The in the patch was copied from MOVSPR(), but since the instruction encoding is different, the shift offsets are also different.

4. In a debugger, stop at the line in asm_stkarg() that calls MOVQSPX, then hand modify r to test both XMM0-7 as well as XMM8-XMM15, in order to ensure the REX.W byte is properly computed.  Step past MOVQSPX(), then disassemble the generated instruction starting at the address in _nIns, to make sure it is valid.  This should be straightforward in VS2008/2010's debugger, or in gdb.

    
  

        Attachment #459735 -
        Flags: review?(edwsmith) → review-

    
  
blocking2.0: ? → beta5+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        v2 (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #459735 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        reftest
        — 
          — Splinter Review
      

    


  

    
    

    
  
Kato-san: is your v2 patch ready for review?

    
    

    
  
This doesn't need to be in b5.
blocking2.0: beta5+ → beta6+

    
  

        Attachment #469829 -
        Flags: review?(edwsmith)

    
  
blocking2.0: beta6+ → betaN+

        Attachment #469829 -
        Flags: review?(edwsmith) → review?(dmandelin)

    
    

    
  
dmandelin, did you mean to ask yourself for a review?

    
    

    
  
Comment on attachment 469829 [details] [diff] [review]
v2

Because of the intricacy of this patch, I have explanatory comments below along with review comments. |*| indicates a review comment/request.

>diff --git a/js/src/nanojit/NativeX64.cpp b/js/src/nanojit/NativeX64.cpp

New function to "compute" REX byte for movqspx. More precisely, the incoming op has the a REX byte of 0x40 already. This function is intended to either mask in the correct REX byte, if one is needed; or else splice out the REX byte.

>+    static inline uint64_t rexspx(uint64_t op, Register r) {
>+        int shift = 64 - 8*oplen(op) + 8;

For |MOVQ mem, reg|, we need a REX byte only if |reg| is past the low 7. So the condition tests that, and if so, returns the original with something masked in (see below). 

The else part handles the case where |reg| is in the low 7. In that case, we copy the prefix byte over the REX byte and decrement the instruction length. This is in parallel with the previous function |rexprb|. I believe this doesn't zero out the old prefix byte, but I assume this is OK as long as the length says to ignore it.

* |rexprb| has a comment for that case. Maybe it should be here too?

* More importantly, the "then" case seems to be sort of a no-op: the REX byte on input is 0x40, so ORing in another 0x40 won't do anything. Maybe 0x44 was wanted here instead? It seems to me that it would be OK to have 0x44 be the REX byte in the header file, since that's what the REX byte will be if we need one, and then have the "then" case simply return |op|.

>+        return r & 8 ? op | 0x40 << shift:
>+               ((op & ~(255LL<<shift)) | (op>>(shift-8)&255) << shift) - 1;
>+    }
>+
>diff --git a/js/src/nanojit/NativeX64.h b/js/src/nanojit/NativeX64.h
>--- a/js/src/nanojit/NativeX64.h
>+++ b/js/src/nanojit/NativeX64.h
>@@ -241,16 +241,17 @@ namespace nanojit
>         X64_learip  = 0x00000000058D4807LL, // 64bit RIP-relative lea. reg <- disp32+rip (modrm = 00rrr101 = 05)
>         X64_movlr   = 0xC08B400000000003LL, // 32bit mov r <- b
>         X64_movbmr  = 0x0000000080884007LL, // 8bit store r -> [b+d32]
>         X64_movsmr  = 0x8089406600000004LL, // 16bit store r -> [b+d32]
>         X64_movlmr  = 0x0000000080894007LL, // 32bit store r -> [b+d32]
>         X64_movlrm  = 0x00000000808B4007LL, // 32bit load r <- [b+d32]
>         X64_movqmr  = 0x0000000080894807LL, // 64bit store gpr -> [b+d32]

* Ed asked for the comment on the following line to be corrected, s/d32/d8.

>         X64_movqspr = 0x0024448948000005LL, // 64bit store gpr -> [rsp+d32] (sib required)

Ed also asked for clarification on the D6. I checked the manual and I also got that D6 is right. I further verified that by using the MSVC disasm on the bytes given here. (Ed mentioned 7E, which is for the "load" version of MOVQ with xmm regs.) 

>+        X64_movqspx = 0x002444D60F406607LL, // 64bit store xmm -> [rsp+d8] (sib required)

So, next steps:

1. Fix REX byte handling for upper 8 registers, or explain why it's right the way it is.

2. Fix old comment per Ed's #2.

3. Check instruction encoding in the debugger per Ed's #4.

        Attachment #469829 -
        Flags: review?(dmandelin)

    
    

    
  
(In reply to comment #21)
> dmandelin, did you mean to ask yourself for a review?

Yes, Ed asked for someone to steal the review request.

    
    

    
  
What's the status of this?  Seems like it's close to being fixed...

    
  
blocking2.0: betaN+ → -

          status2.0:
          --- → wanted

    
    

    
  
Should this really not be blocking2.0? I have come across this bug before and when I last checked it was marked as blocking2.0 but now it's simply marked as "wanted" for 2.0.

Given that it is a clear regression and makes some text completely unreadable, I find it rather puzzling that it has been given such a low priority.

    
    

    
  
Win64 isn't a supported platform for FF4, which is why we're not blocking on it.

    
    

    
  
Also, although this is possible x86-64 nanojit bug, this depends on OS ABI.

Since Win64 ABI passes 4 parameters only by register, so this bug occurs.  If trace jit calls a function (such as DOM method) that 7th or 8th parameter is float/double, this will occurs on Mac or Linux.  But there is no function like this.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix v3 (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #469829 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        v3.1
        — 
          — Splinter Review
      

    


  

        Attachment #521721 -
        Attachment is obsolete: true

    
  

        Attachment #521723 -
        Flags: review?(edwsmith)

    
    

    
  
Comment on attachment 521723 [details] [diff] [review]
v3.1

The patch looks ok to me.

        Attachment #521723 -
        Flags: review?(edwsmith) → review+

    
    

    
  
http://hg.mozilla.org/projects/nanojit-central/rev/6176f4f11b27
Whiteboard: [win64] → [win64] fixed-in-nanojit

    
    

    
  
http://hg.mozilla.org/tracemonkey/rev/c3499d9cf12d
http://hg.mozilla.org/mozilla-central/rev/c3499d9cf12d
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: