#14969 closed bug (fixed)
[UserlandFS] SMAP violation in Volume::ReadAttr
Reported by: | kim1963 | Owned by: | korli |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta2 |
Component: | File Systems/UserlandFS | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #14823 | |
Platform: | All |
Description
SMAP violation rev53000 64 bit
Using SMB Network on desktop.
Attachments (9)
Change History (26)
by , 6 years ago
Attachment: | photo_2019-03-20_14-00-30.jpg added |
---|
by , 6 years ago
Attachment: | listdev.txt added |
---|
by , 6 years ago
Attachment: | sysinfo.txt added |
---|
comment:1 by , 6 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 6 years ago
by , 6 years ago
Attachment: | photo_2019-03-21_10-49-45.jpg added |
---|
by , 6 years ago
Attachment: | photo_2019-03-21_10-49-51.jpg added |
---|
comment:5 by , 6 years ago
kim1963, did you look at my comment https://dev.haiku-os.org/ticket/14969#comment:2 ?
by , 6 years ago
Attachment: | photo_2019-03-24_12-42-50.jpg added |
---|
by , 6 years ago
Attachment: | photo_2019-03-24_12-43-03.jpg added |
---|
comment:6 by , 6 years ago
@korli: I ran all the presumably-loaded kernel images through nm | haikuc++filt
with the guarded heap enabled, and got no crashes whatsoever. So why are we getting read faults on demangling here?
comment:9 by , 6 years ago
Blocking: | 14823 added |
---|
comment:10 by , 6 years ago
FWIIW, I am seeing this too. It is 100% reproducible (happens when trying to browse a share from Tracker). Disabling SMAP/SMEP makes it work (as expected) but sometimes I get some FuseSMB related crashes (last one was when scanning shares, I will create a bug) so I guess this might actually point to a more serious issue with FuseSMB or UserlandFS.
comment:11 by , 6 years ago
This is weird. It seems the kennel is accessing Tracker's memory? It makes sense somewhat as the crash happens when I try to open the smb network icon. I guess this is a userlandfs thing? Because nothing else makes sense
comment:12 by , 5 years ago
Whoever can still reproduce this: Please run sc -d
at the KDL prompt, and take a picture of it.
by , 5 years ago
Attachment: | P_20191124_162919_HDR.jpg added |
---|
comment:14 by , 5 years ago
Component: | - General → File Systems/UserlandFS |
---|---|
Summary: | SMAP violation rev53000 64 bit → [UserlandFS] SMAP violation in Volume::ReadAttr |
comment:16 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
merged, should be fixed in hrev53647. Please reopen if needed.
comment:17 by , 5 years ago
Milestone: | Unscheduled → R1/beta2 |
---|
Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone
Please reproduce and try "area -m 0x0007ffffffffff", replacing 0x0007ffffffffff with the user-mapped address. Then "team 0xff", replacing 0xff with the owner from the area command output. And then
This should help to identify the user memory being passed to the kernel, but I suspect it's a user stack.