Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Object::ID object_id is not stable across threads

Open
#1,413 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
perl
Domain
backend

Research direction

Start with Object::ID's t/threads.t and reproduce the failures on both the JVM and interpreter backends. Trace how Hash::FieldHash stores the parent thread's object ID across child-thread access, then verify that the test passes on both backends and that existing Hash::FieldHash and thread tests remain passing.

Written by the indexing model from the issue text.

Description

bug

Object::ID threaded object identity differs from system Perl

Summary

The CPAN compatibility run for Object::ID v0.1.2 reports 5 failing assertions in t/threads.t. The failure is reproducible on both the JVM backend and the interpreter backend and appears to be a PerlOnJava ithreads/object-identity bug involving the field storage used by Hash::FieldHash.

Evidence
  • CPAN run: 20260916-111623-23683
  • Distribution: Object-ID v0.1.2
  • Test: t/threads.t
  • System Perl: the focused upstream test passes, including all 11 object identity assertions.
  • PerlOnJava JVM backend: 5 of 11 assertions fail.
  • PerlOnJava interpreter backend: 5 of 11 assertions fail.

The failing assertions all have the same shape:

object_id in a thread: got c, expected b

The test creates one object, records its object_id, then checks that the same object has the same ID from five child threads. PerlOnJava assigns a different ID in the child-thread view, while system Perl preserves the identity.

Suspected cause

Object::ID stores IDs in a Hash::FieldHash fieldhash. The parent thread assigns the object ID before starting the threads. When the object is accessed by a child thread, the fieldhash mapping does not appear to be preserved or shared with the cloned object state, so object_id allocates a new ID instead of returning the parent-thread ID.

Because both execution backends reproduce the same result, this is likely in shared thread/object cloning or fieldhash integration rather than in only one compiler backend.

Reverse-dependency impact

MetaCPAN reports 7 released distributions with a runtime dependency on Object::ID; one has a release within the last three years (StorageDisplay). The dependants include StorageDisplay, MooX-Struct, perl5i, Fey-ORM, Role-Commons, Test-Proto, and Module-Install-RDF.

The underlying Hash::FieldHash dependency has 17 released runtime dependants, but none has released within the last three years. This broader count is contextual; the observed defect is specifically threaded use of Object::ID, so the practical affected surface is narrower than the total dependant count.

Suggested acceptance criteria
  1. Object::ID t/threads.t passes on the JVM backend.
  2. The same test passes on the interpreter backend.
  3. The object ID remains stable when the object is accessed from all child threads.
  4. Existing Hash::FieldHash and thread tests continue to pass.
Dominant language
Perl
Stars
64
Forks
6
Avg merge
5h 38m
Merged PRs (30d)
170

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fglock/PerlOnJava

All issues in fglock/PerlOnJava

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.