I recently downloaded the current release, built it and ran vector_test. While it didn't crash, it appears to fail in the sense that the values being read back from the populated vector are often wrong. Oddly enough, many are correct, but many are also not correct.
Is this a known issue? My build platform is RedHat 9....
thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The project was most recently developed under RedHat 9.0, but now that development is switching to Debian Sarge. There is a new version coming out as soon as I get more time to work on it.
I have seen the behavior you describe before, during testing. I think the problem was a lingering shared memory block. So the system was under test, and when it crashed, it did not delete the shared memory segment. A new process was run which then attached to the existing shared memory block, which was corrupted from the earlier crash, and strange values appeared.
In the bin directory there should be a shm_unlink program. Try running that to remove the old shared memory segment and then re-run your test to see if that helps.
Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you're probably right. In my case, I was doing some testing and I have verified it will run through the test correctly at least once...but as soon as I get a bad run, then it's bad until I clean things up (currently a mixture of running shm_unlink and the full test suite in the test/ dir).
I'll look into this further as I adapt some of the concepts to a package I'm integrating into a project of mine. If I find anything definitive that can be back-ported into your code, I'll let you know.
Thanks!
sdm
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Keep in mind that the allocator is designed to attach to an existing shared memory segment. If a segment already exists and is in a corrupted state, it will attach to that segment and start working with it.
As part of your application initialization, you might want to add routines which delete any existing segments which might be leftover from earlier failed runs.
Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recently downloaded the current release, built it and ran vector_test. While it didn't crash, it appears to fail in the sense that the values being read back from the populated vector are often wrong. Oddly enough, many are correct, but many are also not correct.
Is this a known issue? My build platform is RedHat 9....
thoughts?
The project was most recently developed under RedHat 9.0, but now that development is switching to Debian Sarge. There is a new version coming out as soon as I get more time to work on it.
I have seen the behavior you describe before, during testing. I think the problem was a lingering shared memory block. So the system was under test, and when it crashed, it did not delete the shared memory segment. A new process was run which then attached to the existing shared memory block, which was corrupted from the earlier crash, and strange values appeared.
In the bin directory there should be a shm_unlink program. Try running that to remove the old shared memory segment and then re-run your test to see if that helps.
Marc
I think you're probably right. In my case, I was doing some testing and I have verified it will run through the test correctly at least once...but as soon as I get a bad run, then it's bad until I clean things up (currently a mixture of running shm_unlink and the full test suite in the test/ dir).
I'll look into this further as I adapt some of the concepts to a package I'm integrating into a project of mine. If I find anything definitive that can be back-ported into your code, I'll let you know.
Thanks!
sdm
Keep in mind that the allocator is designed to attach to an existing shared memory segment. If a segment already exists and is in a corrupted state, it will attach to that segment and start working with it.
As part of your application initialization, you might want to add routines which delete any existing segments which might be leftover from earlier failed runs.
Marc