[Mono-dev] sgen debugging

Wed Aug 16 23:17:11 UTC 2017

The vtable that you are printing is not a vtable (MONO_TYPE_END is 0). You can see that in major_copy_or_mark_object_with_evacuation ptr and obj are equal which doesn’t make any sense. Looks like something corrupted the static_data that the gc scans. Maybe some bug around mono_alloc_special_static_data or the gc suspended the thread somewhere in an intermediate state.

Vlad

From: Mono-devel-list <mono-devel-list-bounces at lists.dot.net> on behalf of Neale Ferguson <neale at sinenomine.net>
Date: Wednesday, 16 August 2017 at 23:19
To: Mono-Devel <mono-devel-list at lists.ximian.com>
Subject: [Mono-dev] sgen debugging

Apologies for the last email. I thought I'd fixed that problem but Outlook continues to screw me. Using a different client now -

Running a test in mono/tests I get the following:

#0  0x00000000802b7dc0 in par_copy_object_no_checks (objsize=0, obj=0x804ed290, vt=0x804ed290,

    destination=0x3fffab5c130 "") at sgen-copy-object.h:53

#1  copy_object_no_checks (obj=obj at entry=0x804ed290, queue=queue at entry=0x3ffffffec48) at sgen-copy-object.h:80

#2  0x00000000802c31cc in major_copy_or_mark_object_with_evacuation (queue=0x3ffffffec48, obj=0x804ed290,

    ptr=0x804ed290) at sgen-marksweep-drain-gray-stack.h:84

#3  major_copy_or_mark_object_canonical (ptr=0x804ed290, queue=0x3ffffffec48) at sgen-marksweep.c:1358

#4  0x00000000802212c0 in mark_slots (addr=0x804ed290, bitmaps=0x8044c600 <thread_reference_bitmaps>,

    mark_func=0x802a42dc <single_arg_user_copy_or_mark>, gc_data=0x3ffffffe7a8) at threads.c:4013

#5  0x00000000802a4eae in precisely_scan_objects_from (ctx=..., desc=<optimized out>, end_root=0x804ed690,

    start_root=0x804ed290, n_start=<optimized out>, n_end=<optimized out>) at sgen-gc.c:935

#6  scan_from_registered_roots (ctx=..., root_type=<optimized out>, addr_start=<optimized out>,

    addr_end=<optimized out>) at sgen-gc.c:1256

#7  job_scan_from_registered_roots (worker_data_untyped=<optimized out>, job=<optimized out>) at sgen-gc.c:1400

#8  0x00000000802e83c0 in sgen_workers_enqueue_job (generation=<optimized out>, job=0x3fffd07f008,

    enqueue=<optimized out>) at sgen-workers.c:181

#9  0x00000000802a4386 in enqueue_scan_from_roots_jobs (gc_thread_gray_queue=0x3ffffffec48, heap_start=0x0,

    heap_end=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>,

    ops=0x8049d558 <major_collectorﮞ>, enqueue=0) at sgen-gc.c:1640

Gdb shows the SEGV here:

Program received signal SIGSEGV, Segmentation fault.

0x00000000802b7dc0 in par_copy_object_no_checks (objsize=0, obj=0x804ed290, vt=0x804ed290,

    destination=0x3fffab5c130 "") at sgen-copy-object.h:53

53

memcpy ((char*)destination sizeof (mword), (char*)obj sizeof (mword), objsize - sizeof (mword));

(gdb) up

#1  copy_object_no_checks (obj=obj at entry=0x804ed290, queue=queue at entry=0x3ffffffec48) at sgen-copy-object.h:80

80

par_copy_object_no_checks ((char *)destination, vt, obj, objsize);

(gdb) list 65

65

static MONO_NEVER_INLINE GCObject *

66

copy_object_no_checks (GCObject *obj, SgenGrayQueue *queue)

67

{

68

GCVTable vt = SGEN_LOAD_VTABLE_UNCHECKED (obj);

69

gboolean has_references = SGEN_VTABLE_HAS_REFERENCES (vt);

70

mword objsize = SGEN_ALIGN_UP (sgen_client_par_object_get_size (vt, obj));

71

void *destination = COLLECTOR_SERIAL_ALLOC_FOR_PROMOTION (vt, obj, objsize, has_references);

72

73

if (G_UNLIKELY (!destination)) {

74

/* FIXME: Is this path ever tested? */

(gdb) p vt

$5 = (MonoVTable *) 0x804ed290

(gdb) p obj

$6 = (GCObject *) 0x804ed290

(gdb) p *vt

$7 = {klass = 0x804ed290, gc_descr = 0, domain = 0x0, type = 0x0, interface_bitmap = 0x0, max_interface_id = 0,

  rank = 0 '\000', initialized = 0 '\000', remote = 0, init_failed = 0, has_static_fields = 0, gc_bits = 0,

  imt_collisions_bitmap = 0, runtime_generic_context = 0x0, vtable = 0x804ed2d0}

(gdb) p *vt->klass

$8 = {element_class = 0x804ed290, cast_class = 0x0, supertypes = 0x0, idepth = 0, rank = 0 '\000',

  instance_size = 0, inited = 0, size_inited = 0, valuetype = 0, enumtype = 0, blittable = 0, unicode = 0,

  wastypebuilder = 0, is_array_special_interface = 0, min_align = 0 '\000', packing_size = 0, ghcimpl = 0,

  has_finalize = 0, marshalbyref = 0, contextbound = 0, delegate = 0, gc_descr_inited = 0, has_cctor = 0,

  has_references = 0, has_static_refs = 0, no_special_static_fields = 0, is_com_object = 0,

  nested_classes_inited = 0, class_kind = 0, interfaces_inited = 0, simd_type = 0, has_finalize_inited = 0,

  fields_inited = 0, has_failure = 0, parent = 0x0, nested_in = 0x0, image = 0x0, name = 0x0, name_space = 0x0,

  type_token = 0, vtable_size = 0, interface_count = 0, interface_id = 0, max_interface_id = 0,

  interface_offsets_count = 0, interfaces_packed = 0x0, interface_offsets_packed = 0x0,

  interface_bitmap = 0x3fffafd8130 "", interfaces = 0x0, sizes = {class_size = 1023, element_size = 1023,

    generic_param_token = 1023}, fields = 0x0, methods = 0x3fffafd8270, this_arg = {data = {klass = 0x0,

      type = 0x0, array = 0x0, method = 0x0, generic_param = 0x0, generic_class = 0x0}, attrs = 0,

    type = MONO_TYPE_END, num_mods = 0, byref = 0, pinned = 0, modifiers = 0x804ed33c}, byval_arg = {data = {

      klass = 0x0, type = 0x0, array = 0x0, method = 0x0, generic_param = 0x0, generic_class = 0x0}, attrs = 0,

    type = MONO_TYPE_END, num_mods = 0, byref = 0, pinned = 0, modifiers = 0x804ed34c}, gc_descr = 0,

  runtime_info = 0x0, vtable = 0x0, infrequent_data = {head = 0x0}}

I am wondering what MONO_TYPE_END is and whether it should be looked at by gc or what might have happened to get me to this point?

Neale

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170816/db94df0c/attachment-0001.html>