Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
Don-t-use-debian-in-autoconf.patch | Don't use debian/ in autoconf | Ole Streicher <olebole@debian.org> | no | 2020-08-02 | ||
Correct-manpage-hyphens.patch | Correct manpage hyphens | Ole Streicher <olebole@debian.org> | no | 2015-01-24 | ||
Make-multibuf-and-multiwbuf-static.patch | Make multibuf and multiwbuf static These two variables appear in two different files, but they are only used locally. This patch separates them by making them static. |
Ole Streicher <olebole@debian.org> | no | 2015-01-25 | ||
Replace-the-build-date-with-the-last-changed-date-of-conf.patch | Replace the build date with the last changed date of configure.ac This shall help to make the build reproducible. |
Ole Streicher <olebole@debian.org> | no | 2015-05-28 | ||
Remove-suspicious-threshold.patch | Remove suspicious threshold These lines did reset the variance (for the resampled weight image) to zero when they are below the configured threshold (which is, by default 1e10 (!)). . The code there is executed after the code from src/weight.c, where the threshold already was applied. Setting them to zero based on a lower limit seems not to be useful. |
Ole Streicher <olebole@debian.org> | yes | 2016-01-24 | ||
Fix-deadlock-segfault-when-running-with-many-overlapping-.patch | Fix deadlock/segfault when running with many overlapping frames I built a single-threaded copy of SWarp to bypass the thread deadlock only to find it died of a seg fault at another point in the code. A bit of debugging with gdb revealed the code was using a signed int to offset into the coadd buffer which, by requesting a large image size and large number of overlapping frames, was causing the offset counter to wrap into negative values so that memory addresses outside the buffer were being referenced. This of course caused the segmentation fault. I "fixed" this by casting the offset to unsigned during the calculation of the base line addresses in coadd_line() before they're used in any further pointer arithmetic. This is not a general solution as I can imagine someone out there wanting even more frames or larger image size than me, thus triggering the problem again when the unsigned int isn't wide enough. Perhaps using unsigned long or unsigned int64_t would be better? Anyway, I re-enabled multi-threading afterwards and found that my fix also prevented the thread deadlock as well! |
Debian Astronomy Maintainers | no | 2019-01-26 |