OutOfMemoryError in TimephasedDataFactory (16.7.0) reading MPP with an inverted-time TimephasedItem; MPXJ 16.6.0 rejects the same item cleanly

[mcallegario]

MPXJ version: 16.7.0 (regression — 16.6.0 does not crash on the same file)
Java version: Microsoft Build of OpenJDK 21.0.10 (21.0.10+7-LTS)
OS: Reproduced on both Windows and Linux
Entry point: UniversalProjectReader.read(path) on a .mpp file (MPP14 format), ~1.45 MB

Summary

Reading a specific .mpp file with MPXJ 16.7.0 causes an OutOfMemoryError inside TimephasedDataFactory.getCompleteWork() / splitItem(), regardless of heap size (reproduced with -Xmx512m, -Xmx2048m, and -Xmx6144m — all fail the same way, during a single call to MPP14Reader.processAssignmentData). The file is not large (~1.4 MB), which suggests the allocation is effectively unbounded rather than merely large.

Downgrading only the MPXJ dependency to 16.6.0 (no other code changes) reads the same file successfully, but exposes the underlying cause: several ResourceAssignments in this file contain a raw TimephasedItem where start is after finish (an inverted/invalid time window). MPXJ 16.6.0 rejects these with a clean IllegalArgumentException; MPXJ 16.7.0 appears to loop/recurse without terminating when it encounters the same data.

The 16.7.0 changelog lists exactly one change in this area for that release:

"When reading MPP files, improve handling of timephased data items with durations of less than one hour."

The invalid items found (see table below) mostly have short durations (some under 1 hour) or, in one case, a negative totalAmount, which lines up with that changelog entry. My working hypothesis is that the updated short-duration handling in splitItem doesn't validate start < finish before splitting, and enters a loop that never converges when fed one of these inverted items — hence the unbounded ArrayList growth in the stack trace below. I have not stepped through the 16.7.0 source with a debugger to confirm this directly; flagging it as the most likely mechanism based on the stack trace + changelog + version-diff behavior.

Stack trace (MPXJ 16.7.0)

java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.Arrays.copyOf(Arrays.java:3513)
	at java.base/java.util.Arrays.copyOf(Arrays.java:3482)
	at java.base/java.util.ArrayList.grow(ArrayList.java:237)
	at java.base/java.util.ArrayList.grow(ArrayList.java:244)
	at java.base/java.util.ArrayList.add(ArrayList.java:483)
	at java.base/java.util.ArrayList.add(ArrayList.java:496)
	at org.mpxj.mpp.TimephasedDataFactory.splitItem(TimephasedDataFactory.java:300)
	at org.mpxj.mpp.TimephasedDataFactory.getCompleteWork(TimephasedDataFactory.java:164)
	at org.mpxj.mpp.ResourceAssignmentFactory.process(ResourceAssignmentFactory.java:211)
	at org.mpxj.mpp.MPP14Reader.processAssignmentData(MPP14Reader.java:1731)
	at org.mpxj.mpp.MPP14Reader.process(MPP14Reader.java:101)
	at org.mpxj.mpp.MPPReader.read(MPPReader.java:164)
	at org.mpxj.reader.UniversalProjectReader$2.read(UniversalProjectReader.java:613)
	at org.mpxj.reader.UniversalProjectReader.read(UniversalProjectReader.java:252)
	at org.mpxj.reader.UniversalProjectReader.read(UniversalProjectReader.java:240)

(remaining frames are my application's own call stack into UniversalProjectReader.read(), omitted as not relevant)

Invalid TimephasedItem instances found (via MPXJ 16.6.0's clean rejection)

Recovered by downgrading to 16.6.0 and logging the IllegalArgumentException: Item start must be before item end messages it throws from ResourceAssignment.getTimephasedWork/getTimephasedActualWork/getTimephasedCost/getTimephasedActualCost:

start	finish	totalAmount	amountPerHour
2026-01-05T18:00	2026-01-05T15:00	-24.615 (negative)	8.205
2026-02-24T09:00	2026-02-23T18:00	5.334	5.334
2026-02-02T10:45	2026-01-29T17:15	0.019	0.076
2026-02-06T09:00	2026-02-05T18:00	45.0	60.0
2026-02-06T09:00	2026-02-05T18:00	45.0	60.0 (identical to previous row — likely a linked/copied assignment)

In every case start is later than finish, never the reverse — this looks systematic rather than random corruption, though I don't know the write path in MS Project that produces it.

Additional finding: not isolated to a specific time window

I tried requesting getTimephasedWork/getTimephasedCost etc. one narrow range at a time (instead of one call covering the whole assignment) to see if only a subset of ranges would fail. Result: 100% of the ranges failed with the identical exception for the affected assignments. This indicates the exception is thrown while MPXJ builds the assignment's complete internal timephased representation from the raw MPP data — before any range-based filtering happens — so no client-side workaround (requesting smaller windows) can avoid it.

Reproduction

I can't share the original file (customer project data). Comparing behavior between 16.6.0 and 16.7.0 on the same file is fully reliable evidence of the regression, but if it helps, I'm happy to try to build and share a minimal synthetic .mpp reproducing an inverted-time TimephasedItem if someone can point me to how such an item could be produced (a specific manual work-split edit near a day boundary in MS Project, resource leveling, etc.) — I haven't yet found a reliable way to construct one from scratch.

Suggested fix direction

TimephasedDataFactory.splitItem/getCompleteWork should validate start < finish (and non-negative amount) before attempting to split an item, and reject/skip invalid items the way 16.6.0's higher-level getTimephasedWork/getTimephasedCost methods already do via a controlled exception — rather than (apparently) looping/recursing without terminating.

[joniles]

Thanks for opening this issue. I do really need to have a sample file to work from to solve this. You can create a sample file by copying the file you are working with (don't use Save As in MS Project as this will rewrite the file and may lose the structure which is causing the issue). You can then delete all of the tasks and resources apart from the task with the problem timephased data and any resources assigned to it, and rename the task and any remaining resources. At this point the file should no longer contain any sensitive information about the project. You can then email the file directly to me rather than posting it publicly: my contact details can be found here: https://www.mpxj.org/support/.

[joniles]

@mcallegario apologies, but I haven't heard back from you so I'm going to close this issue now. If you can send me a file which replicates the problem I'd be happy to take a look.

[drixouuk]

I confirm this issue. I can't share the file either, sorry — it belongs to a client
project. Here is everything I measured on it, in case it helps you find it without
a sample.

Environment (reproduces 100% of the time):

• MPXJ 16.7.0 (Python wrapper mpxj==16.7.0, so mpxj.jar 16.7.0), regression verified
  against 16.6.0
• OpenJDK 21.0.12.1, Apache POI 5.5.1, log4j-api 2.24.3, Debian 13, Python 3.11.16
• Entry point: UniversalProjectReader.read(path) on a 1.8 MB binary .mpp

Symptoms:

• 16.7.0: java.lang.OutOfMemoryError: Java heap space inside a single read() call.
  Reproduced with -Xmx512m, 1024m, 1536m, 4g, 5g and 6g. Larger heaps only take
  longer to die, so the allocation is effectively unbounded.
• Heap dump at -Xmx512m, taken at the OOM: 13,824,476 instances of
  org.mpxj.TimephasedWork (~632 MB retained). The file is 1.8 MB and its OLE
  container holds 1.6 MB of stream payload over 106 streams, so those objects
  cannot be coming from the file.
• 16.6.0 reads the same file in ~1 s with a ~119 MB peak: 310 tasks (272 detail
  tasks), 280 assignments, 224 links — and it returns ZERO timephased entries for
  the assignments. Nothing is logged or rejected (I put log4j-core on the classpath
  to surface MPXJ's log output; it stays silent).

Ruled out by measurement, in case it narrows the search:

• not the file's timephased payload (16.6.0 exposes none, 16.7.0 still explodes)
• not the presentation data: setReadPresentationData(false) → same ~13.8 M objects
• not setUseRawTimephasedData(true) → identical
• not the VBA project: emptying the VBA streams changes nothing
• not size/task/link counts: other plans up to 11.8 MB and 24,000 tasks read in a
  few seconds on the same build

Suggestion, given that the file can't leave the client:
The stack entry point from the original report
(MPP14Reader.processAssignmentData -> TimephasedDataFactory.getCompleteWork ->
splitItem) matches what I see here. Diffing TimephasedDataFactory between 16.6.0
and 16.7.0 is probably enough: 16.6.0 threw "IllegalArgumentException: Item start
must be before item end" for an invalid item, and it looks like 16.7.0 lost or
bypassed that guard on a path whose loop bound depends on the item's own fields —
hence an unbounded loop allocating one TimephasedWork per iteration. A defensive
bound, plus a logged warning instead of a silent skip, would turn that into a loud
failure instead of a heap exhaustion.

A synthetic unit test may reproduce it with no real file at all: build a
ResourceAssignment holding a timephased item where start > finish (or with a
zero-length / negative range) and call TimephasedDataFactory.getCompleteWork()
directly. If that loops, you have a reproducer in a few lines.