Bug #17552
closed[PATCH] Fix a NULL pointer crash in ObjectSpace.dump_all
Description
Patch: https://github.com/ruby/ruby/pull/4078
I wasn't able to reproduce the issue in isolation just yet, but I confirmed the patch fixes the issue for us.
What seem to happen in that some objects have an allocation_info
, but allocation_info->path == NULL
.
What is weird is that in 2.7.2, there was no NULL check for ->path
, it was directly passed to vfprintf
, which from what I understand would have generated "path": (null)
, which is invalid JSON.
So I suspect allocation_info { path = NULL }
wasn't possible on 2.7.2?
Either way I'd like to write a test case for this, but I'm still unable to find a way to create an object with a NULL path
.
Updated by byroot (Jean Boussier) about 3 years ago
So with some extra debug code, I've managed to identify the object that causes this, it's only one object on a multi-GiB dump:
{"address":"0x7f32c8b8d6c8", "type":"IMEMO", "class":"0x8", "imemo_type":"ment", "generation":57, "memsize":48, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}}
I don't know wether this is expected or not, the "class":"0x8"
is particularly surprising.
Updated by tenderlovemaking (Aaron Patterson) about 3 years ago
- Status changed from Open to Closed
- Backport changed from 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN to 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: REQUIRED
This is fixed in 6ca3d1af3302f722aed530764d07c1cc83e95ecf
Updated by naruse (Yui NARUSE) about 3 years ago
- Backport changed from 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: REQUIRED to 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: DONE
ruby_3_0 06da90a146346d6968a8716a9035ede7104c0f97 merged revision(s) 6ca3d1af3302f722aed530764d07c1cc83e95ecf.