View Issue Details

IDProjectCategoryView StatusLast Update
0008110Talerexchangepublic2024-08-12 10:11
Reporterfefe Assigned ToFlorian Dold  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status feedbackResolutionopen 
Target Versionpost-2.0 
Summary0008110: feature request: library functions should not abort the process
DescriptionThe Taler code is based on Gnunet, which will wrap memory allocations to abort the process if they fail. It also uses Gnunet assertions which will abort the process if a condition is not met.

This can be argued to produce less complex and therefore more readable code if you write code for an application, but I think we should reopen the discussion for code you ship as a library for others to use. Many library users will find it not acceptable if their GUI application just crashes after the response from the exchange triggered some internal inconsistency check assertion.

Library code should never crash the application, not unintentionally and also not intentionally. Logic bugs like refcount overflows should be detected and handled, but not through crashing the application.

The library should return an error instead and make sure not to leak ressources in the error path. The calling application should get the opportunity to display a nice error message instead of just crashing.
TagsNo tags attached.

Relationships

child of 0008112 assignedfefe Merchant security review 

Activities

Christian Grothoff

2024-01-18 22:31

manager   ~0020911

I still disagree, handling these super-insane errors (like out-of-memory, or RC exceeds 4 billion) would also for the applications using this likely not be an adequately tested path. *Our* memory consumption is also rather tiny (for any GUI), so *we* are unlikely to blame, and most GUIs I know will also not survive out-of-memory situations. The actual main user of the library are again Taler services that are single-threaded and auto-restarted and in fact periodically auto-killed by systemd, so they _expect_ this behavior, too. Again, for simplicity in their design to avoid too complex error handling. I'm happy to *document* this limitation (or feature), but not exactly seeing that you could change my mind here.

Christian Grothoff

2024-01-23 18:53

manager   ~0020998

Added comment in header that the library is expected to be used-single threaded and may abort() on out-of-memory situations.
To clarify: this is a *reference* implementation showcasing _how_ one would interact with the REST API that is also used by a single-threaded auto-restarted merchant backend.
It is not expected to be used 'everywhere', we have re-implementations in TypeScript and PHP for some of the functions, and I fully expect more language bindings in the future.

Issue History

Date Modified Username Field Change
2024-01-18 17:18 fefe New Issue
2024-01-18 17:18 fefe Status new => assigned
2024-01-18 17:18 fefe Assigned To => Christian Grothoff
2024-01-18 22:31 Christian Grothoff Note Added: 0020911
2024-01-18 22:31 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2024-01-18 22:31 Christian Grothoff Status assigned => feedback
2024-01-18 23:31 Christian Grothoff Relationship added child of 0008112
2024-01-23 18:39 Christian Grothoff Target Version => post-1.0
2024-01-23 18:53 Christian Grothoff Note Added: 0020998
2024-01-23 18:55 Christian Grothoff Severity minor => feature
2024-08-12 10:11 Christian Grothoff Target Version post-1.0 => post-2.0