View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003908 | Taler | wallet (WebExtension) | public | 2015-07-22 18:11 | 2019-12-26 21:37 |
| Reporter | Marcello Stanisci | Assigned To | Marcello Stanisci | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0003908: Non-deterministic behaviour due to parameters order in emscripted functions, mostly for 64-bit values | ||||
| Description | some emscritped functions, especially the ones with 64-bit wide values among their parameters, use to show different behaviours according to the order in which some of the formal parameters are defined. For example, foo(uint64_t n, char* str) { printf("%lld, %s\n", n, str); } does not print the expected string. To do so, we must invert the order in the definition, so that 'str' comes before 'n'. That interferes with those functions used to sum amounts and build signatures involving amounts, because we need to pass them a currency name (= char *) and some bare uint64_t values which those functions use to properly define TALER_Amount structures. As of now, functions such as TALER_amount_get_zero are called with a hardcoded "EUR" in their parameters. This bug could also be the cause for which the signature is judged invalid by the mint (and valid by local verification): the summed amount of denomination+withdrawal_fee is returned by a function that does have 64-bit values in its parameters, so it might generate a different amount respect to the one re-generated locally by the mint at verification phase. | ||||
| Steps To Reproduce | compile wrap.c with emscripten and call (from inside firefox) DEBUG_WR_test_string by trying both parameters order | ||||
| Tags | No tags attached. | ||||
| parent of | 0003883 | closed | Marcello Stanisci | Check whether a reserve has the desired amount of money |
| parent of | 0003762 | closed | Marcello Stanisci | wallet needs to support /withdraw/sign to withdraw coins |
|
|
this blocks the comparison of different amounts too, useful when checking if a desired amount has been loaded into some reserve |
|
|
That's due to how emscripten passes 64-bit values to compiled functions: it redefines the compiled function replacing its 64-bit parameter with two 32-bit ones, Hi and Lo. Not advertised on [1], but "hidden" in [2]. One solution could be splitting the 64-bit values in JavaScript land and pass the two 32-bit Hi and Lo values to the compiled function, as suggesetd in [3] (second comment). Although JavaScript natively represents numbers 64-widely, in [4] is pointed out that it's not as accurate as C, so when the wallet parses the JSON it got from the mint it actually could change a bit that value; in this case, the Hi and Lo values would represent a different value respect to the one stored in the mint. Possible solutions: 1. the mint gives to the wallet a *string* representing the 64-bit wide number 2. defining some error tolerance and split the value in Hi and Lo anyway. [1] http://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html [2] http://kripken.github.io/emscripten-site/docs/api_reference/preamble.js.html#calling-compiled-c-functions-from-javascript [3] https://github.com/kripken/emscripten/issues/2265 [4] https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/Using_js-ctypes/Working_with_data#64-bit_integers |
|
|
parameters' order trickery solved in 39bf404..f16a126, though the current policy of getting amounts by the mint needs a confirmation/modification. One solution could be filtering the parsing (see 'revival' parameter of JSON.parse) by using ctypes UInt64 |
|
|
Because of the way of handling numbers by JavaScript, both servers and clients should rely on arithmetic up to 53 bits. To be added to the specs. |
|
|
A note has been added in 5aa5fc5..69ca174 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-07-22 18:11 | Marcello Stanisci | New Issue | |
| 2015-07-22 18:11 | Marcello Stanisci | Status | new => assigned |
| 2015-07-22 18:11 | Marcello Stanisci | Assigned To | => Marcello Stanisci |
| 2015-07-23 11:54 | Marcello Stanisci | Note Added: 0009478 | |
| 2015-07-23 12:14 | Marcello Stanisci | Relationship added | parent of 0003883 |
| 2015-07-23 12:14 | Marcello Stanisci | Relationship added | parent of 0003762 |
| 2015-07-23 12:17 | Marcello Stanisci | Note Edited: 0009478 | |
| 2015-07-23 14:59 | Marcello Stanisci | Note Added: 0009480 | |
| 2015-07-23 18:44 | Marcello Stanisci | Note Added: 0009481 | |
| 2015-07-27 08:49 | Marcello Stanisci | Note Edited: 0009481 | |
| 2015-07-27 14:35 | Marcello Stanisci | Note Added: 0009485 | |
| 2015-07-29 11:25 | Marcello Stanisci | Note Added: 0009505 | |
| 2015-07-29 11:25 | Marcello Stanisci | Status | assigned => resolved |
| 2015-07-29 11:25 | Marcello Stanisci | Resolution | open => fixed |
| 2015-08-02 21:45 | Christian Grothoff | Product Version | => git (master) |
| 2015-08-02 21:45 | Christian Grothoff | Fixed in Version | => 0.0 |
| 2015-08-02 21:45 | Christian Grothoff | Target Version | => 0.0 |
| 2015-08-02 21:46 | Christian Grothoff | Status | resolved => closed |
| 2019-12-26 21:37 | Florian Dold | Category | wallet (browser-based) => wallet (WebExtensions) |
| 2023-04-13 20:37 | Florian Dold | Category | wallet (WebExtensions) => wallet (WebExtension) |
