Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #391 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

interface based comparison in fiber causes crash

Reported by: drox Assigned to: sean
Priority: major Milestone: 0.99 RC3
Component: Core Functionality Version: trunk
Keywords: Cc:

Description

this code crashes reliably on dmd 1.012 and gdc 0.23, on ubuntu linux x86 the code is a bit long but I don't know what the problem is... basically there is a DelayedCall? object that encapsulates an arbitrary function or delegate. Then I create a delegate from a Fiber that pushes a few DelayedCall? objects onto a heap.

Attachments

buggy.d (0.5 kB) - added by drox on 04/15/07 15:36:17.
simplified code to reproduce crash

Change History

04/15/07 15:36:17 changed by drox

  • attachment buggy.d added.

simplified code to reproduce crash

04/15/07 15:42:28 changed by drox

  • summary changed from classinfo is null to interface based comparison in fiber causes crash.

this is as simple as I could make the code

either of these things will cause the code to not trigger the bug: not using a fiber and calling fun(), getting rid of IDelayedCall entirely and using DelayedCall? for the opCmp type

it doesn't matter if I make a new fiber every time or use the same one and reset() it

04/15/07 15:45:57 changed by drox

removing the instance variable f and the assignment in the ctor will also cause the code to no longer crash

04/19/07 16:19:57 changed by drox

  • version set to trunk.

05/05/07 01:58:19 changed by sean

  • status changed from new to assigned.

05/12/07 13:46:46 changed by larsivi

  • milestone set to 0.99 RC3.

05/22/07 14:29:33 changed by sean

  • status changed from assigned to closed.
  • resolution set to fixed.

It turns out that the actual problem is related to the Fiber/GC integration code. In short, if a collection occurs while a Fiber is running and before the first time that Fiber has called Fiber.yield(), any data uniquely referenced by that Fiber will be cleaned up by the GC. This was because Thread.m_lock was not being cleared when a Fiber is first called.

See http://dsource.org/projects/tango/forums/topic/96#451 for more discussion.

Fixed by changeset [2240].