You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[INFO] Tests run: 288, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.043 s -- in org.json.junit.JSONObjectNumberTest
[INFO] Running org.json.junit.JSONObjectTest
new BigDecimal(testData[]) : 42 ms
NUMBER_PATTERN.matcher(testData[]).matches() : 38 ms
[ERROR] Tests run: 108, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 0.457 s <<< FAILURE! -- in org.json.junit.JSONObjectTest
[ERROR] org.json.junit.JSONObjectTest.issue743SerializationMapWith1000Objects -- Time elapsed: 0.012 s <<< ERROR!
java.lang.StackOverflowError
at org.json.JSONObject.wrap(JSONObject.java:2645)
at org.json.JSONObject.wrap(JSONObject.java:2618)
at org.json.JSONObject.<init>(JSONObject.java:314)
The text was updated successfully, but these errors were encountered:
@vaukai@matoro Thanks for posting.
I cannot recreate this bug. I am guessing it might be a resource problem with your build config, but for some reason you have to run the unit tests on it. What would you consider to be an acceptable solution to this issue?
@vaukai@matoro Thanks for posting. I cannot recreate this bug. I am guessing it might be a resource problem with your build config, but for some reason you have to run the unit tests on it. What would you consider to be an acceptable solution to this issue?
We're distro maintainers validating that the package works on our supported architectures, which includes 32-bit x86, and passing the test suite is what we use as the primary indication the package works.
If by resource problem you mean system resources, that's definitely not the case, as the tests pass just fine in a 64-bit environment on the same host. What process did you use to recreate the bug? This requires a 32-bit chroot or 32-bit install.
Ah, OK, that explains why it doesn't recreate for me. Testing the ability to handle deeply nested JSON docs is important, but I suppose the actual number can be adjusted. Do you want to try tweaking the number of objects created in that test to find your upper limit?
The downstream bug report is https://930723.bugs.gentoo.org/attachment.cgi?id=891802.
Need to add, Gentoo does not use Maven or Gradle but builds directly with
javac
.Can you help?
Adding the log from
mvn test
: https://930723.bugs.gentoo.org/attachment.cgi?id=891918The text was updated successfully, but these errors were encountered: