-
Notifications
You must be signed in to change notification settings - Fork 413
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Panic in dlmalloc after upgrading to Rust 1.78.0 #1389
Comments
Happy to help debug/investigate further with some pointers for where to look to generate more info |
We're seeing it here too, but doesn't seem to help to downgrade to rust 1.77.1. |
Just want to link some details here too: alexcrichton/dlmalloc-rs#41 (comment) alexcrichton/dlmalloc-rs#41 (comment) In summary, after 1.78 enabled debug assertions in |
This issue seems to be resolved in latest main and 0.2.92 version, will paste my comment on the issue I opened in dlmalloc: alexcrichton/dlmalloc-rs#41 For anyone landing on this issue, it seems that in the latest revision on
https://github.com/rustwasm/wasm-bindgen/blob/0.2.92/CHANGELOG.md#fixed-1 OR
https://github.com/rustwasm/wasm-bindgen/blob/0.2.92/CHANGELOG.md#0287 |
Just For anyone who is still stuck, I solved this by downgrading back to |
same error |
I upgraded to |
Upgrading wasm-bindgen to latest worked for me |
same error, rust 1.83 and wasm-bindgen 0.2.99:
|
Another crate with broken allocator behavior? Glad to see WASM is as debuggable as ever though ^-^ I often write a shim allocator to log/test for allocation behavior. I haven't tried it before, but I wonder if https://lib.rs/crates/checkers could provide some more info. (Typically, it's just a matter of finding out which crate and calls are doing unsafe allocation management badly. Unfortunately I don't think I'll have the time to dig into this one in the near future.) |
I'd be happy to provide test case and source code to reproduce the bug, forgot to mention but the issue is (at least) in the Here's the payload you can use in the html textarea ( <html>
<head>
<title>Notulen</title>
</head>
<body
prefix='eli: http://data.europa.eu/eli/ontology# prov: http://www.w3.org/ns/prov# mandaat: http://data.vlaanderen.be/ns/mandaat# besluit: http://data.vlaanderen.be/ns/besluit# ext: http://mu.semte.ch/vocabularies/ext/ person: http://www.w3.org/ns/person# foaf: http://xmlns.com/foaf/0.1/ lblodlg: http://data.lblod.info/vocabularies/leidinggevenden/ skos: http://www.w3.org/2004/02/skos/core# persoon: https://data.vlaanderen.be/ns/persoon# dc: http://purl.org/dc/terms/ '>
<div id="editor" class="ember-application">
<div class="editor">
<div id="ember245" class="editor__paper ember-view">
<div>
<div class='ext_metadata' contenteditable='false' property='ext:metadata'>
<div typeof='besluit:Zitting'
resource='https://data.destelbergen.be/zittingen/8b9fe347-4c93-ee11-be37-000d3ad8b15b'>
<span property='besluit:heeftNotulen'
resource='https://destelbergen.powerappsportals.com/zittingen/?id=a6a451c4-601f-ef11-840a-002248a03ee0'
typeof='foaf:Document'></span>
<span property='eli:passed_by'
resource='http://data.lblod.info/id/bestuursorganen/cd9ddb549bfc87477be14071944f0bcae5a468aa2e912dd59f1534d9e28f871a'
typeof='besluit:Bestuursorgaan'></span>
<div class='container'>
<div class='row py-3'>
<div class='col'><img
src='https://www.destelbergen.be/sites/default/files/2023-01/dest-logo_0.svg'
style='max-width:250px'></div>
<div class='col'>
<h6 class='text-uppercase text-right'>Notulen</h6>
</div>
</div>
<div class='row'>
<div class='col'>
<h1 class='text-uppercase text-center'>Gemeenteraad</h1>
</div>
</div>
<div class='row py-3'>
<div class='col'>
<p id='ccp_publisheddate'></p>
</div>
<div class='col'>
<h6 class='text-right' property='dc:title'
id='8b9fe347-4c93-ee11-be37-000d3ad8b15b'>
<span
resource='http://data.lblod.info/id/bestuursorganen/cd9ddb549bfc87477be14071944f0bcae5a468aa2e912dd59f1534d9e28f871a'
typeof='besluit:Bestuursorgaan'
property='besluit:isGehoudenDoor'></span>
Zitting van <span property='besluit:geplandeStart'
content='2024-04-18T17:46:39Z' datatype='xsd:dateTime'>donderdag 18
april 2024</span>
<span class='annotation' property='prov:atLocation' datatype='xsd:string'
content='Destelbergen'></span>
<span property='prov:startedAtTime' datatype='xsd:dateTime'
content='2024-04-18T17:46:39Z'></span>
<span property='prov:endedAtTime' datatype='xsd:dateTime'
content='2024-04-18T19:00:00Z'></span>
</h6>
</div>
</div>
<div class='row py-5'>
<div class='col'>
<p property='ext:insertAanwezigenText'>
<span class='font-weight-bold'>Aanwezig: </span>
<span property='besluit:heeftVoorzitter'
resource='http://data.lblod.info/id/mandatarissen/5F33F82AF9D30200080002C5'
typeof='mandaat:Mandataris'>Ben D'Haene</span>
</p>
</div>
</div>
<div class='row'>
<div class='col'>
<h4>Stemmingen</h4>
<p>
<span class='font-weight-bold'>Aanwezig: </span>
<span property='besluit:heeftAanwezige'
resource='http://data.lblod.info/id/mandatarissen/5D69204AA3ACB6000900033B'
typeof='mandaat:Mandataris'>
<span property='mandaat:isBestuurlijkeAliasVan' resource=''
typeof='person:Person'>
<span property='persoon:gebruikteVoornaam'>Henriette</span>
<span property='foaf:familyName'>Scheire</span>
</span>(
<span property='org:holds'
resource='http://data.lblod.info/id/mandaten/387293fe1088c6291c86a2f60cd4133c86cc464ed0e54b9ceaf12d04b5ff1f23'
typeof='mandaat:Mandaat'>
<span property='org:role'
resource='http://data.vlaanderen.be/id/concept/BestuursfunctieCode/5ab0e9b8a3b2ca7c5e000011'
typeof='skos:Concept'>
<span property='skos:prefLabel'>Gemeenteraadslid
</span>
</span>
</span>)</span>,
<br />
</p>
<br />
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>
|
When it comes to bad deallocations/reallocations, last time I checked, lol_alloc would "leak" memory (I.e. lose track of parts of its allocation arena). Not sure if it's possible to corrupt memory by supplying the wrong allocation Layout to lol_alloc - never heard of it happening. Regardless, just something to watch out for. dlmalloc checks that the allocations are reasonable, if not, panics. talc will run into weird panics, so will galloc. lol_alloc silently does wrong things. They all have their different behavior for various reasons. Either way, the code has UB and demons could be flying out of your nostrils, but in practice using lol_alloc while someone fixes their code is probably fine. |
🐛 Bug description
After upgrading to Rust toolchain 1.78.0, I started getting this error in my GitHub pages project when compiling to wasm:
Compiling with the exact same code, this does not happen with 1.77.1.
🤔 Expected Behavior
No panic
👟 Steps to reproduce
Code compiled to wasm:
Command used to build:
The
.wasm
output is being served in https://github.com/jtroo/jtroo.github.io, which can easily be served locally, e.g.🌍 Your environment
Include the relevant details of your environment.
wasm-pack version: 0.12.1
rustc version: 1.78.0 / 1.77.1
The text was updated successfully, but these errors were encountered: