Heyheyhey,
Unfortunately, these bugs are only found when doing your release builds and
finding it is not working like in debug mode.
Then when investigating the problem, you could (if you're lucky) bring it
back to few lines, indicating where the problem is.
I cannot imagine that any one would have found such a bug just by thinking
of a scenario like described in the few lines of code, since no-one would
use that kind of code in real world code ... ha!
Hence, the compile bug found by Richard. :P
// Ryan
-----Original Message-----
From: Richard Blewett
To: [EMAIL PROTECTED]
Sent: 28-08-2003 21:13
Subject: Re: [ADVANCED-DOTNET] [inbox] Re: [ADVANCED-DOTNET] Nasty bug in
1.0 and 1.1 compiler
Ahh but we found this in production code (or code destined for
production in
the near future.
This is the real scenario:
We have a TimedLock class that internally calls TryEnter on a monitor -
basically to allow is not to perform an infinite wait like the lock
keywork
does. We wanted it scode based and so implemented the release of the
lock in
IDisposable.Dispose so we had usage as follows
using( TimedLock.Lock(obj) )
{
// some stuff that needs thread safe access via obj
}
However, in one scenario, simply being able to acquire the lock meant
that
the resource we were locking was ready for use therefore we simply
needed to
immediately release the lock and use the resource in a readonly fashion.
So we had code like this
if( myhashtable.ContainsKey(s) )
{
using( TimeLock.Lock(s) )
{
}
}
else
{
// need to create the s entry in the hashtable and populate it
}
return myhashtable[s];
so you see its not lunatic coding that led us to discover this
Regards
Richard Blewett
DevelopMentor
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill
Sent: 28 August 2003 17:52
To: [EMAIL PROTECTED]
Subject: [inbox] Re: [ADVANCED-DOTNET] Nasty bug in 1.0 and 1.1 compiler
Ouch. That's actually more serious than the original -- I would not
have
imagined anyone needing (or thinking) to write a "using" statement with
an
empty body. When would that be necessary (or even useful)?
In this code, do you need both the TRY and FINALLY blocks to be empty to
see
the bug? That's also not a likely real-world construct, is it?
At 06:18 AM 8/28/2003 -0400, Richard Blewett wrote
>On Thu, 28 Aug 2003 03:53:19 -0400, Vijay M <[EMAIL PROTECTED]> wrote:
>
>>>commenting out the using block in the if block or putting code after
the
>>>using block in the if resolves the problem
>>
>>Richard, i am not quite able to understand the solution for this bug.
It
>>would be really helpful for many of us if you can explain it in more
detail
>>on why such a confusion in the compiler happens in the first place and
why
>>the using block is responsible for creating this behaviour.
>>
>
>Vijay, unfortunately I am not privy to the C# compiler code and so have
no
>idea why it is unable to deal with this situation.
>
>I don't think its the using block per se as I have translated it into
the
>try/finally block that using resolves to and the error still remains.
Here
>is the absolute bare bones to repro the problem
>
><code>
>class App
>{
> static void Main(string[] args)
> {
> if( args.Length == 0 )
> {
> Console.WriteLine("in if");
> try
> {
> }
> finally
> {
> }
> }
> else
> {
> Console.WriteLine("in else");
> }
> }
>}
></code>
>
>Regards
>
>Richard Blewett
>DevelopMentor
J. Merrill / Analytical Software Corp
===================================
This list is hosted by DevelopMentor� http://www.develop.com
NEW! ASP.NET courses you may be interested in:
2 Days of ASP.NET, 29 Sept 2003, in Redmond
http://www.develop.com/courses/2daspdotnet
Guerrilla ASP.NET, 13 Oct 2003, in Boston
http://www.develop.com/courses/gaspdotnet
View archives and manage your subscription(s) at
http://discuss.develop.com
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003
===================================
This list is hosted by DevelopMentor� http://www.develop.com
NEW! ASP.NET courses you may be interested in:
2 Days of ASP.NET, 29 Sept 2003, in Redmond
http://www.develop.com/courses/2daspdotnet
Guerrilla ASP.NET, 13 Oct 2003, in Boston
http://www.develop.com/courses/gaspdotnet
View archives and manage your subscription(s) at
http://discuss.develop.com
-------------------------------------
The information included in this message is personal and/or confidential and
intended exclusively for the addressees as stated. This message and/or the
accompanying documents may contain confidential information and should be
handled accordingly. If you are not the intended reader of this message, we
urgently request that you notify Centric immediately and that you delete
this e-mail and any copies of it from your system and destroy any printouts
immediately.
It is forbidden to distribute, reproduce, use or disclose the information in
this e-mail to third parties without obtaining prior permission from
Centric. We expressly point out that there are risks associated with the use
of e-mail. Centric and the companies within the group shall not accept any
liability whatsoever for damage resulting from the use of e-mail. Legally
binding obligations can only arise for Centric by means of a written
instrument, signed by an authorized representative of Centric.
-------------------------------------
===================================
This list is hosted by DevelopMentor� http://www.develop.com
NEW! ASP.NET courses you may be interested in:
2 Days of ASP.NET, 29 Sept 2003, in Redmond
http://www.develop.com/courses/2daspdotnet
Guerrilla ASP.NET, 13 Oct 2003, in Boston
http://www.develop.com/courses/gaspdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
