<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=SV link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US>Hi Dave<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>I would like to discuss the usage of FAULT_ON_ERROR in readmem calls. I have now seen a number of situations where this prevents Crash to produce appropriate results when some memory is corrupt.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>The last problem I saw a few days ago was in kernel.c, in function dumplog<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US> readmem(log_buf, KVADDR, buf,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US> log_buf_len, "log_buf contents", FAULT_ON_ERROR)<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>The problem was that log_buf_len contained a very large value (memory overwrite?) so the readmem failed due to the size. This means of course that it was not possible to print the log, but as this function is called during Crash startup it also had the consequence that Crash terminated during startup. By just changing FAULT_ON_ERROR to RETURN_ON_ERROR and perform a return if the readmem failed I could use Crash to investigate this vmcore file, except for printing the log.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>A second place where I have made some patches in Crash is in function arm_uvtop (arm.c). In the readmem calls in this function I have changed FAULT_ON_ERROR to RETURN_ON_ERROR and just made a "return FALSE;" if the readmem fails. Unfortunately I do not remember the details why I made this change, but I think there were a case where Crash terminated during startup and with these changes it was possible to investigate the vmcore file.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Another situation I have seen is in help functions like fill_vma_cache and fill_file_cache. When I use these functions in extensions the commands will fail and terminate immediately if a readmem call fails. In several cases I could easily handle such a failure and the command could still produce a lot of relevant results.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>In the plugins I write I use RETURN_ON_ERROR in principle everywhere and of course then handle the error situations myself. I have done this to avoid situations as the ones described above.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>I am not asking you to remove most usage of FAULT_ON_ERROR, as I realize the size and risks with such changes. However I would like to bring up this question and hear your views. When working with vmcore files with minor memory corruptions, using FAULT_ON_ERROR will limit the usability of Crash.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Jan<o:p></o:p></span></p><div><div><div><p class=MsoNormal><span lang=EN-US style='font-family:"Helvetica","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Helvetica","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal style='mso-line-height-alt:10.5pt'><b><span lang=EN-US style='font-size:11.5pt;font-family:"Helvetica","sans-serif";color:black'>Jan Karlsson</span></b><b><span lang=EN-US style='font-size:11.5pt;font-family:"Helvetica","sans-serif";color:black'><o:p></o:p></span></b></p><p class=MsoNormal style='line-height:10.5pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Helvetica","sans-serif";color:#222222'>Senior Software Engineer<o:p></o:p></span></p><p class=MsoNormal style='line-height:10.5pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Helvetica","sans-serif";color:#222222'>MIB<o:p></o:p></span></p><p class=MsoNormal style='line-height:10.5pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Helvetica","sans-serif";color:#222222'> <o:p></o:p></span></p><p class=MsoNormal style='line-height:10.5pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Helvetica","sans-serif";color:#222222'>Sony Mobile Communications<o:p></o:p></span></p><p class=MsoNormal style='line-height:10.5pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Helvetica","sans-serif";color:#222222'>Tel: +46703062174<o:p></o:p></span></p><p class=MsoNormal style='line-height:10.5pt'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif";color:#002AFF'><a href="http://sonymobile.com/"><span style='color:#002AFF'>sonymobile.com</span></a><o:p></o:p></span></p><p class=MsoNormal style='mso-line-height-alt:12.75pt'><span style='font-size:13.0pt;font-family:"Helvetica","sans-serif";color:#222222'> <o:p></o:p></span></p><p class=MsoNormal><img border=0 width=102 height=35 id="Picture_x0020_1" src="cid:image001.jpg@01CD84FD.28EB6440" alt="SONY make.believe"><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p></span></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>