Skip to content

Conversation

@TomasHofman
Copy link
Contributor

https://issues.redhat.com/browse/UNDERTOW-1859

@fl4via for your consideration.

The test doesn't terminate because occasionally int res = response.write(buffer) on line 94 returns 0, which causes the thread to return and not execute the exchange.endExchange(); I think.

@fl4via fl4via added the enhancement Enhances existing behaviour or code label May 10, 2023
@TomasHofman
Copy link
Contributor Author

TomasHofman commented May 15, 2023

The WriteTimeoutTestCase now fails in the "proxy" profile with:

java.lang.RuntimeException: Buffer Leak io.undertow.server.WriteTimeoutTestCase.testWriteTimeout[proxy]
	at io.undertow.testutils.DefaultServer$1.testFinished(DefaultServer.java:403)
	at org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
	at org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
	at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
	at org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
	at org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at io.undertow.testutils.DefaultServer.runChild(DefaultServer.java:706)
	at io.undertow.testutils.DefaultServer.runChild(DefaultServer.java:144)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at io.undertow.testutils.RunDefaultServer.evaluate(RunDefaultServer.java:74)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at io.undertow.testutils.DefaultServer.run(DefaultServer.java:376)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Caused by: java.lang.RuntimeException: java.nio.DirectByteBuffer[pos=0 lim=8192 cap=8192] NO: 188480 [NO_CONTEXT]
	at io.undertow.testutils.DebuggingSlicePool$DebuggingBuffer.<init>(DebuggingSlicePool.java:84)
	at io.undertow.testutils.DebuggingSlicePool.allocate(DebuggingSlicePool.java:45)
	at io.undertow.util.Transfer$TransferListener.handleEvent(Transfer.java:170)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at io.undertow.channels.DetachableStreamSourceChannel$SetterDelegatingListener.handleEvent(DetachableStreamSourceChannel.java:228)
	at io.undertow.channels.DetachableStreamSourceChannel$SetterDelegatingListener.handleEvent(DetachableStreamSourceChannel.java:215)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)

@TomasHofman
Copy link
Contributor Author

On my laptop the failures don't happen always, but often enough. Running mvn test -Dtest=WriteTimeoutTestCase -f core/ -Pproxy there is several surefire executions (proxy, proxy-https, ...), at least some of those executions fail always.

The "Caused by: java.lang.RuntimeException: ..." portion of the stack trace above shows where the leaking buffer was initialized, and this stack trace is different in various surefire executions, depending on which conduits are configured etc...

So far I don't understand what's causing the leak.

@fl4via fl4via added the failed CI Introduced new regession(s) during CI check label Jun 7, 2023
@fl4via fl4via added waiting CI check Ready to be merged but waiting for CI check under verification Currently being verified (running tests, reviewing) before posting a review to contributor failed CI Introduced new regession(s) during CI check and removed failed CI Introduced new regession(s) during CI check waiting CI check Ready to be merged but waiting for CI check labels Oct 17, 2025
@fl4via
Copy link
Member

fl4via commented Oct 17, 2025

Yep, we will need to investigate this a little further. Basically, it seems this fix undecovered another underlying issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Enhances existing behaviour or code failed CI Introduced new regession(s) during CI check under verification Currently being verified (running tests, reviewing) before posting a review to contributor

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants