Opened 7 years ago

Closed 7 years ago

#685 closed defect (fixed)

cdfs crashes when trying to mount HelenOS boot CD

Reported by: Jiri Svoboda Owned by: Jiri Svoboda
Priority: major Milestone: 0.7.1
Component: helenos/unspecified Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:


With latest mainline and amd64 when I try mounting the boot CD, cdfs crashes (and the command line hangs).

I tried the same with revisions as old as 2408 (December 2015) where it had to work (because sysinst is introduced later) with the same result. That means it cannot be a regression in HelenOS. My current tool that is called to create the ISO image (Fedora genisoimage called as mkisofs) must have started doing something different that cdfs doesn't like.

Attachments (2)

cdfs-crash-1.png (30.1 KB ) - added by Jiri Svoboda 7 years ago.
Mounting the boot CD
cdfs-crash-2.png (32.7 KB ) - added by Jiri Svoboda 7 years ago.
Stack trace (kcon)

Download all attachments as: .zip

Change History (8)

by Jiri Svoboda, 7 years ago

Attachment: cdfs-crash-1.png added

Mounting the boot CD

by Jiri Svoboda, 7 years ago

Attachment: cdfs-crash-2.png added

Stack trace (kcon)

comment:1 by Jiri Svoboda, 7 years ago

The screen shots are from revision 2408. In current rev 2688, the crash occurs in cdfs_readdir() on address 1b76:

                        buf[i] = uint16_t_be2host(((uint16_t *)data)[i]);
    1b5e:       66 0f ef d2             pxor   %xmm2,%xmm2
    1b62:       48 29 c7                sub    %rax,%rdi
    1b65:       48 01 c0                add    %rax,%rax
    1b68:       4d 8d 04 06             lea    (%r14,%rax,1),%r8
    1b6c:       48 89 fe                mov    %rdi,%rsi
    1b6f:       4c 01 e8                add    %r13,%rax
    1b72:       48 c1 ee 03             shr    $0x3,%rsi
    1b76:       66 41 0f 6f 08          movdqa (%r8),%xmm1
    1b7b:       48 83 fe 01             cmp    $0x1,%rsi
    1b7f:       66 0f 6f c1             movdqa %xmm1,%xmm0
    1b83:       66 0f 6f d9             movdqa %xmm1,%xmm3

comment:2 by Jiri Svoboda, 7 years ago

Note that this is a general protection fault, not a page fault. Note that the faulting instruction is movdqa (move aligned double quadword). Looks like the problem is that data is at an odd address, but we're reading it as a 16-bit value. The compiler generated movdqa instruction which generates GP if the adress is not actually aligned.

comment:3 by Jiri Svoboda, 7 years ago

The problem was we were trying to read the UCS2 file names word-by-word (in the C source), but they were starting at an odd address. Interestingly enough, the compiler generates SSE instructions and reads the string in units of 128 bits (16 bytes). I didn't look into this in detail, but it seems the code is generated so that it deals with any even address, but not with odd addresses.

comment:4 by Jiri Svoboda, 7 years ago

Fixed in changeset:mainline,2689 using unaligned_uint16_t * from unaligned.h.

comment:5 by Jiri Svoboda, 7 years ago

Owner: set to Jiri Svoboda
Status: newassigned

comment:6 by Jiri Svoboda, 7 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.