| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0002901 | LibParserUtils | [All Projects] General | public | 2026-08-14 01:07 | 2026-10-06 17:07 | ||||||||
| Reporter | Ismael Luceno | ||||||||||||
| Assigned To | |||||||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||||||
| Status | feedback | Resolution | reopened | ||||||||||
| Product Version | |||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0002901: Crashes due to divergent inline function | ||||||||||||
| Description | This seems to be the same issue as 0002871. I caught this bug after updating libparserutils 0.2.5 while continuing using a libcss compiled against 0.2.4; it caused netsurf to crash immediately after launching. In libparserutils 0.2.5 a new member was added to the top of struct parserutils_buffer, shifting all fields, but because at least parserutils_inputstream_peek is inline in the header, it gets stale; it's dereferencing .alloc while wanting .data, and faults while accessing the end of the buffer crossing a page boundary. This is serious ABI breakage, major-version should be updated. | ||||||||||||
| Steps To Reproduce | Build libcss against libparserutils 0.2.4 then upgarde to libparserutils 0.2.5. | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Fixed in CI build # | |||||||||||||
| Reported in CI build # | |||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
John-Mark Bell (administrator) 2026-10-05 21:29 Last edited: 2026-10-05 21:31 |
As noted in https://bugs.netsurf-browser.org/mantis/view.php?id=2871#c2442 there are no ABI stability guarantees at all for the component libraries unless and until they reach a major version of 1 or greater. |
Ismael Luceno (reporter) 2026-10-06 06:59 |
Perhaps make the SONAME ship the full version (MAJOR.MINOR.PATCH) for 0.x, then only MAJOR.MINOR; that bypasses the issue entirely with no extra work on your part and can be applied at buildsystem level. Does that sound good? I can provide a patch. |
|
John-Mark Bell (administrator) 2026-10-06 17:07 |
We'd be happy to consider patches, yes. Note that the default build configuration (and the one we use) is to build these as static libraries, so all/any such conflicts must be resolved at build time anyway in that mode. In all honesty, supporting these as standalone shared libraries is not very high on our priority list so there are probably other things that don't quite work correctly when building/using them that way. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-08-14 01:07 | Ismael Luceno | New Issue | |
| 2026-10-05 21:29 | John-Mark Bell | Status | new => resolved |
| 2026-10-05 21:29 | John-Mark Bell | Resolution | open => won't fix |
| 2026-10-05 21:29 | John-Mark Bell | Note Added: 0002496 | |
| 2026-10-05 21:31 | John-Mark Bell | Note Edited: 0002496 | View Revisions |
| 2026-10-06 06:59 | Ismael Luceno | Status | resolved => feedback |
| 2026-10-06 06:59 | Ismael Luceno | Resolution | won't fix => reopened |
| 2026-10-06 06:59 | Ismael Luceno | Note Added: 0002524 | |
| 2026-10-06 17:07 | John-Mark Bell | Note Added: 0002525 | |
| Issue History |