Release build optimizations
-
Hi, I'm facing a weird issue on one of my applications on a customers machine. I cannot reproduce it on my machine but I'm trying to understand what might have happened according to the log. Basically the following code is executed:
public override bool Modify(LabelProperties properties, object[] values)
{
try
{
if(values[0] == null)
return false;int sourceIndex = Convert.ToInt32(((Key)values\[0\]).Value); //some other code but no further conversions}
catch (Exception exc)
{
_log.Error("Modify - " + exc.Message, exc);
try
{
_log.Info("Key Value: " + ((Key)values[0]).Value);
}
catch {}
return false;
}
return false;
}The following information gets logged: 10:58:07 | Error | HiddenCategoryFeaturesLabelModifier::Modify - Die Eingabezeichenfolge hat das falsche Format. at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) at DE.IVU.FilialInfo.Map.ThematicMaps.Modifiers.HiddenCategoryFeaturesLabelModifier.Modify(LabelProperties properties, Object[] values) Two things seem weird to me: 1. Although I'm using
Convert.ToInt32onlySystem.Number.ParseInt32is logged with the call stack. 2. The log call in the exception handler isn't done, which is weird because the first exception occurs in the number conversion routine. Thus I assume the cast and the property getterValueare working fine. But why aren't they within the handler? Basically my question is if this behavior can be explained with the optimizations happening in the optimized release build. Does optimization really replace higher level calls with lower level calls? (Just as a note:_logis alog4net.ILoginstance and I assume it is working correctly. At least I didn't have any issues with it till now). -
Hi, I'm facing a weird issue on one of my applications on a customers machine. I cannot reproduce it on my machine but I'm trying to understand what might have happened according to the log. Basically the following code is executed:
public override bool Modify(LabelProperties properties, object[] values)
{
try
{
if(values[0] == null)
return false;int sourceIndex = Convert.ToInt32(((Key)values\[0\]).Value); //some other code but no further conversions}
catch (Exception exc)
{
_log.Error("Modify - " + exc.Message, exc);
try
{
_log.Info("Key Value: " + ((Key)values[0]).Value);
}
catch {}
return false;
}
return false;
}The following information gets logged: 10:58:07 | Error | HiddenCategoryFeaturesLabelModifier::Modify - Die Eingabezeichenfolge hat das falsche Format. at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) at DE.IVU.FilialInfo.Map.ThematicMaps.Modifiers.HiddenCategoryFeaturesLabelModifier.Modify(LabelProperties properties, Object[] values) Two things seem weird to me: 1. Although I'm using
Convert.ToInt32onlySystem.Number.ParseInt32is logged with the call stack. 2. The log call in the exception handler isn't done, which is weird because the first exception occurs in the number conversion routine. Thus I assume the cast and the property getterValueare working fine. But why aren't they within the handler? Basically my question is if this behavior can be explained with the optimizations happening in the optimized release build. Does optimization really replace higher level calls with lower level calls? (Just as a note:_logis alog4net.ILoginstance and I assume it is working correctly. At least I didn't have any issues with it till now).Hi, 1. Although I'm using Convert.ToInt32 only System.Number.ParseInt32 is logged with the call stack. As far as I know,
Convert.ToInt32does a check fornullparameters and then passes the parameter to lower level methods. However, I still would have expected to seeConvert.ToInt32in the stack trace. 2. The log call in the exception handler isn't done, which is weird because the first exception occurs in the number conversion routine. Thus I assume the cast and the property getter Value are working fine. But why aren't they within the handler? The_log.Errorcall is done, therefore I assume the_log.Infocall is done, too. What filters do you have applied to the log? I typically set the log4net filter level to WARN or ERROR in release versions.Regards, Tim
-
Hi, 1. Although I'm using Convert.ToInt32 only System.Number.ParseInt32 is logged with the call stack. As far as I know,
Convert.ToInt32does a check fornullparameters and then passes the parameter to lower level methods. However, I still would have expected to seeConvert.ToInt32in the stack trace. 2. The log call in the exception handler isn't done, which is weird because the first exception occurs in the number conversion routine. Thus I assume the cast and the property getter Value are working fine. But why aren't they within the handler? The_log.Errorcall is done, therefore I assume the_log.Infocall is done, too. What filters do you have applied to the log? I typically set the log4net filter level to WARN or ERROR in release versions.Regards, Tim
I'm logging all levels. To be sure I just made a quick check and saw many other log entries of type Info (even coming from the same logger instance) but this one is missing.
-
Hi, I'm facing a weird issue on one of my applications on a customers machine. I cannot reproduce it on my machine but I'm trying to understand what might have happened according to the log. Basically the following code is executed:
public override bool Modify(LabelProperties properties, object[] values)
{
try
{
if(values[0] == null)
return false;int sourceIndex = Convert.ToInt32(((Key)values\[0\]).Value); //some other code but no further conversions}
catch (Exception exc)
{
_log.Error("Modify - " + exc.Message, exc);
try
{
_log.Info("Key Value: " + ((Key)values[0]).Value);
}
catch {}
return false;
}
return false;
}The following information gets logged: 10:58:07 | Error | HiddenCategoryFeaturesLabelModifier::Modify - Die Eingabezeichenfolge hat das falsche Format. at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) at DE.IVU.FilialInfo.Map.ThematicMaps.Modifiers.HiddenCategoryFeaturesLabelModifier.Modify(LabelProperties properties, Object[] values) Two things seem weird to me: 1. Although I'm using
Convert.ToInt32onlySystem.Number.ParseInt32is logged with the call stack. 2. The log call in the exception handler isn't done, which is weird because the first exception occurs in the number conversion routine. Thus I assume the cast and the property getterValueare working fine. But why aren't they within the handler? Basically my question is if this behavior can be explained with the optimizations happening in the optimized release build. Does optimization really replace higher level calls with lower level calls? (Just as a note:_logis alog4net.ILoginstance and I assume it is working correctly. At least I didn't have any issues with it till now).The Convert.ToInt32(string) method just checks for a null value, then calls Int32.Parse. It's quite possible that this code is inlined by the compiler. The inlined code would in that case resemble:
string temp = ((Key)values[0]).Value;
int sourceIndex = (temp == null) ? 0 : Int32.Parse(temp, NumberStyles.Integer, NumberFormatInfo.CurrentInfo);--- b { font-weight: normal; }