I'm just trying ML out for the first time tonight. I'm using the latest nightly(build 3-09-2014.) I get the error 'raw_rec_task: NULL PTR' at the end of any video. By any video, I mean it happens both at the end of forced stopped video that occurs due to my low card speed and happens when im shooting continuous video at lower resolutions then pressing the stop button. I'm just wondering if that's normal. The footage seems to be ok besides some pink frames, which I understand is normal.
It's not normal. Do you have some more info about the error? If you upload your ML/SETTINGS directory, we can try to reproduce it.
Can anyone reproduce the issue on other cameras?
This is the output from the last crash log(1 is generated for every video I have created.)
[7] raw_rec_task: NULL PTR (0,e1a00000)
pc= 2 lr= 0 stack=162160+0x1000
entry=bd3830(0)
e1a00000 e59ff005 e59ff014 e59ff014
e59ff014 e1a00000 e59ff010 e59ff010
Magic Lantern version : v2.3.NEXT.2014Mar09.600D102
Mercurial changeset : b7b428c610ef (unified) tip
Built on 2014-03-09 01:59:26 UTC by
[email protected].
Free Memory : 206K + 833K
My ML/SETTINGS directory - http://www.datafilehost.com/d/9b5ad573
I should note that this error was happening before I enabled dual iso or mlv player.
The same problem on my 600D, too.
[100] raw_rec_task: NULL PTR (0,e1a00000)
pc= 2 lr= 0 stack=162160+0x1000
entry=bbc7b0(0)
e1a00000 e59ff005 e59ff014 e59ff014
e59ff014 e1a00000 e59ff010 e59ff010
Magic Lantern version : v2.3.NEXT.2014Mar06.600D102
Mercurial changeset : 9969f7e19324 (unified)
Built on 2014-03-06 22:12:14 UTC by edgar@linux-uoww.
Free Memory : 250K + 1033K
looks like the crash doesn´t happen in crop-mode.
Edgar
edit:
do you need a core dump?
Can you try loading the mem_prot module? Maybe it provides some more useful information.
With this modul loaded no more crash
Edgar
Okay, but does it catch any error in menu?
That´s all. I can see:
(https://farm4.staticflickr.com/3432/13060860405_ba1f946daf.jpg) (https://www.flickr.com/photos/112024673@N05/13060860405/)
VRAM0 (https://www.flickr.com/photos/112024673@N05/13060860405/) von seescho (https://www.flickr.com/people/112024673@N05/) auf Flickr
Exceptions are counting up from 0, I guess to ...
Edgar
I'm confused... why this one shows CLR_CALC and the other shows raw_rec_task?
Does it have anything to do with small hacks? Are silent pictures OK? Is mlv_rec fine?
silents give no crash and mlv_rec is fine, too. Small hacks are disabled.
I will try later, with which nightly this fault is introduced.
Edgar
nightly from 10.2.2014: no error
nightly from 11.2.2014: Camera hangs and blinks SOS, if inserting akku
nightly from 12.2.2014: Crash error is shown
Edgar
Good catch. Can you locate the guilty changeset with hg bisect?
For those changesets where the camera blinks SOS, simply remove some stuff from features.h to get some free RAM.
edgar@linux-uoww:~/ML/escho-magiclantern> hg bisect --good
Die erste fehlerhafte Revision ist:
Änderung: 9252:4c11c09dcc4d
Zweig: unified
Nutzer: alex@thinkpad
Datum: Mon Feb 10 12:00:01 2014 +0200
Zusammenfassung: Re-enabled CONFIG_TSKMON, but disabling it during raw recording to avoid performance penalty
I hope, I did all correct with this bisect-stuff
Edgar
This means, the error was present before, but went undetected. TSKMON is the thing that detects such errors.
Can you try bisecting with the mem_prot module? It does not depend on TSKMON, and you may have to try some older changesets.
Hmm, nice :o
Tried this, but too many compile errors appear in earlier builds, which I cannot solve. So I must give up here, sorry
Edgar
tskmon.c
Commenting this out let the error dissapeare
#ifdef HIJACK_TASK_ADDR
// if (RECORDING_RAW)
// {
/* we need full speed; these checks might cause a small performance hit */
// return;
// }
if (sensor_cleaning)
{
/* 5D2 locks up, even with loop of of asm("nop"); maybe others too? */
return;
}
???
Edgar
#if defined(CONFIG_600D)
/* Ignore CLR_CALC NPE
*/
if (streq(task_name, "CLR_CALC"))
return;
#endif
So it's this one being triggered while recording. But why it's fine with mlv?
Just enabled small hacks and the error has gone.
Edgar
... and if I disable the extra hacks in mlv_rec, I have this error in mlv_rec, too! These small (extra) hacks are the reason, raw rec had the error and mlv_rec didn´t. Since 2 days small hacks are enabled per default in raw_rec, too, so the error will not appeare anymore, if you don´t disable the small hacks.
That´s a way to avoid this error, but that doesn´t mean, the real reason of this error is found.
Edgar
Great find.
Curious which of the small hacks triggers this bug (it might be a clue for understanding what's going on).
raw_rec.c
/* disable auto exposure and auto white balance */
//call("aewb_enableaewb", unhack ? 1 : 0); /* for new cameras */
call("lv_ae", unhack ? 1 : 0); /* for old cameras */
call("lv_wb", unhack ? 1 : 0);
error
/* disable auto exposure and auto white balance */
call("aewb_enableaewb", unhack ? 1 : 0); /* for new cameras */
//call("lv_ae", unhack ? 1 : 0); /* for old cameras */
//call("lv_wb", unhack ? 1 : 0);
no error
Edgar
Wait, must test once more, something went wrong!
OK, confirmed!
Hehe, good old aewb, which eats CPU time even when disabled...
600D may have both sets of commands?
I can confirm I am experiencing the same issues on the 600D as the OP is. Stopping RAW capture generates this error.
Committed a fix here (https://bitbucket.org/hudson/magic-lantern/pull-requests/778/raw-fixes-part-3).
I'm unable to reproduce the issue, so it's untested. Please report.
(side note: other reports for this bug can be found by searching for "null ptr" on the forum or on the issue tracker)
Hmm,
I tried to force the error with the nightly from 16. Dez. 2016 on my 600D. Extra-hacks in mlv_rec, small-hacks in raw-rec are disabled. No null ptr error anymore, even without your fix.
The reports from 2016 about this issue were on 700D, 60D, 1200D and EOS M. Not sure what causes it, but I can imagine a way to fake the issue (e.g. by creating a task named like Canon's, which modifies *(int*)0). It's a Canon bug, btw; ML simply checks for such bugs on each DryOS context switch.
The checks are not performed during raw recording, for speed reasons. Therefore, once the raw recording stops (something done from raw_rec_task), the checker notices the bug as soon as DryOS switches to another task. Therefore, the error message will report raw_rec_task as the source of the error, even if some other task did it.
The fix restores the null pointer checks during raw recording, but keeps the other (expensive) checks disabled.