Hyperion Entertainment Message Boards

Hello,

I thought to make an alias for the shell recording facility, and that's where I noticed the following:

When I stop recording, but have "to <file> off" or "off to <file>" on the command line, Grim Reaper produces a DSI error.

> version full shell.kmod
shell 53.7 (29.9.09)

I've never used the "recorder", so be gentle with me...

Please tell me exactly what you did, what you typed, what happened.
Is this an Update 3 system? If not, what level of release?
What version of console.device and con-handler are you using?
Please don't post the whole crash log, just the name from the "Crashed Process:" line and the "Stack backtrace" if you can.

tonyw wrote:I've never used the "recorder"

I haven't used it much either, I prefer stdout redirection.

It's a 4.1u3 system. Of course the syntax isn't "correct" in the latter
case, this is so a single alias might be used.

1. Opened shell window by FKey.
2. Entered "recorder TO RAM:recording". Responded as should.
(optional shell use, did nothing this time)
3. Entered "recorder TO RAM:recording off". It stopped recording ie. it output its message claiming so. Grim Reaper then.

console.device 53.1 (11.6.08)
con-handler 53.1 (11.6.08)

Crash log excerpt:
Crash log for task "recorder"
Generated by GrimReaper 53.2
Crash occured in module kernel at address 0x0141F3D0
Type of crash: DSI (Data Storage Interrupt) exception
-
Shell Process [recorder] (Crashed)
Stack: 0x6807d004 - 0x680b8ffc, pointer @ 0x680b8d60 (Cookie OK)
Signals: SigRec 0x00000100, SigWait 0x00000100
State: Process (Crashed)

4. -> gdb backtrace:
#0 0x0141f3d0 in ?? ()
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 64 realreg: 67
#1 0x0141f3d0 in ?? ()
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 64 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
#2 0x0141f3d0 in ?? ()
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 64 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
#3 0x0141f3d0 in ?? ()
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 64 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
#4 0x0141f3d0 in ?? ()
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 64 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
trad_frame_addr_p: 0
trad_frame_realreg_p: 1
trad_frame_value_p: 0
alt 2, regnum: 67 realreg: 67
#5 0x0141f3d0 in ?? ()
Previous frame inner to this frame (corrupt stack?)

Yes, you are quite right, it does, even with the current beta updates.

I'll write a bug report and maybe even look into it myself.

(edit) It's an internal Shell function so I'd better leave it to Olaf. However, I can see that if you type:
"recorder to <file>", then "recorder off" (without repeating the file name), it does not crash, so you can work around the problem with that.

It only crashes if you repeat the file name with the "off" option.

(edit 2) Bug report #7298.