View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004174 | Taler | mechant backend | public | 2016-02-16 20:38 | 2021-09-02 18:22 |
| Reporter | Marcello Stanisci | Assigned To | Florian Dold | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.0 | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0004174: segfault if malformed JSON POSTed | ||||
| Description | Although the backend returns a 'invalid json' message, it segfaults anyways. No valgrind log attached since it just mentions an 'Illegal instruction' error without telling where in the source code ... | ||||
| Steps To Reproduce | POST bogus JSON to any backend's API call accepting POSTed JSONs | ||||
| Tags | No tags attached. | ||||
|
|
Does the merchant have a test harness right now so we can add some regression tests for this? Also, might this be related to 0004109? |
|
|
Just FYI, here's the valgrind output: Feb 17 01:59:18-376154 taler-merchant-httpd-30479 WARNING Failed to parse JSON request body ==30479== Jump to the invalid address stated on the next line ==30479== at 0xE132772: ??? ==30479== by 0x566EF32: MHD_connection_handle_idle (connection.c:2750) ==30479== by 0x5673B49: MHD_run_from_select (daemon.c:2333) ==30479== by 0x5673EC2: MHD_select (daemon.c:2476) ==30479== by 0x567396A: MHD_run (daemon.c:3007) ==30479== by 0x402DD8: run_daemon (taler-merchant-httpd.c:311) ==30479== by 0x5AD7E15: run_ready (scheduler.c:587) ==30479== by 0x5AD7E15: GNUNET_SCHEDULER_run (scheduler.c:868) ==30479== by 0x5AD309D: GNUNET_PROGRAM_run2 (program.c:302) ==30479== by 0x5AD337E: GNUNET_PROGRAM_run (program.c:341) ==30479== by 0x403DF3: main (taler-merchant-httpd.c:593) ==30479== Address 0xe132772 is 30 bytes before a block of size 16 in arena "client" ==30479== vex amd64->IR: unhandled instruction bytes: 0x2F 0x65 0x74 0x63 0x2F 0x6C 0x6F 0x63 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==30479== valgrind: Unrecognised instruction at address 0xe132790. ==30479== at 0xE132790: ??? ==30479== by 0x566EF32: MHD_connection_handle_idle (connection.c:2750) ==30479== by 0x5673B49: MHD_run_from_select (daemon.c:2333) ==30479== by 0x5673EC2: MHD_select (daemon.c:2476) ==30479== by 0x567396A: MHD_run (daemon.c:3007) ==30479== by 0x402DD8: run_daemon (taler-merchant-httpd.c:311) ==30479== by 0x5AD7E15: run_ready (scheduler.c:587) ==30479== by 0x5AD7E15: GNUNET_SCHEDULER_run (scheduler.c:868) ==30479== by 0x5AD309D: GNUNET_PROGRAM_run2 (program.c:302) ==30479== by 0x5AD337E: GNUNET_PROGRAM_run (program.c:341) ==30479== by 0x403DF3: main (taler-merchant-httpd.c:593) ==30479== Your program just tried to execute an instruction that Valgrind ==30479== did not recognise. There are two possible reasons for this. ==30479== 1. Your program has a bug and erroneously jumped to a non-code ==30479== location. If you are running Memcheck and you just saw a ==30479== warning about a bad jump, it's probably your program's fault. ==30479== 2. The instruction is legitimate but Valgrind doesn't handle it, ==30479== i.e. it's Valgrind's fault. If you think this is the case or ==30479== you are not sure, please let us know and we'll try to fix it. ==30479== Either way, Valgrind will now raise a SIGILL signal which will ==30479== probably kill your program. ==30479== ==30479== Process terminating with default action of signal 4 (SIGILL) ==30479== Illegal opcode at address 0xE132790 ==30479== at 0xE132790: ??? ==30479== by 0x566EF32: MHD_connection_handle_idle (connection.c:2750) ==30479== by 0x5673B49: MHD_run_from_select (daemon.c:2333) ==30479== by 0x5673EC2: MHD_select (daemon.c:2476) ==30479== by 0x567396A: MHD_run (daemon.c:3007) ==30479== by 0x402DD8: run_daemon (taler-merchant-httpd.c:311) ==30479== by 0x5AD7E15: run_ready (scheduler.c:587) ==30479== by 0x5AD7E15: GNUNET_SCHEDULER_run (scheduler.c:868) ==30479== by 0x5AD309D: GNUNET_PROGRAM_run2 (program.c:302) ==30479== by 0x5AD337E: GNUNET_PROGRAM_run (program.c:341) ==30479== by 0x403DF3: main (taler-merchant-httpd.c:593) ==30479== ==30479== HEAP SUMMARY: ==30479== in use at exit: 287,896 bytes in 3,517 blocks ==30479== total heap usage: 261,864 allocs, 258,347 frees, 8,270,260 bytes allocated ==30479== ==30479== LEAK SUMMARY: ==30479== definitely lost: 200 bytes in 1 blocks ==30479== indirectly lost: 0 bytes in 0 blocks ==30479== possibly lost: 1,086 bytes in 32 blocks ==30479== still reachable: 286,610 bytes in 3,484 blocks ==30479== suppressed: 0 bytes in 0 blocks ==30479== Rerun with --leak-check=full to see details of leaked memory ==30479== ==30479== For counts of detected and suppressed errors, rerun with: -v ==30479== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Illegal instruction |
|
|
It seems that the segfault only happens with /backend/hash-contract, posting invalid JSON to other endpoints works fine (even twice). |
|
|
Segfault also happens with /backend/contract ... (but not with /backend/pay) |
|
|
I've found the cause: The merchant backend was expecting the MHD connection_cls to have a certain format (a struct where the first field is a cleanup callback). The cleanup callback is executed for all requests. This was violated by /backend/contact and /backend/hash-contract, and caused some unrelated pointer to be executed as cleanup callback. This should be better documented in the code ... |
|
merchant: master 75a01337 2016-02-17 04:05 Details Diff |
fix 0004174 |
Affected Issues 0004174 |
|
| mod - src/backend/taler-merchant-httpd.c | Diff File | ||
| mod - src/backend/taler-merchant-httpd.h | Diff File | ||
| mod - src/backend/taler-merchant-httpd_contract.c | Diff File | ||
| mod - src/backend/taler-merchant-httpd_pay.c | Diff File | ||
| mod - src/backend/taler-merchant-httpd_util.c | Diff File | ||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-02-16 20:38 | Marcello Stanisci | New Issue | |
| 2016-02-16 20:38 | Marcello Stanisci | Status | new => assigned |
| 2016-02-16 20:38 | Marcello Stanisci | Assigned To | => Marcello Stanisci |
| 2016-02-17 01:42 | Florian Dold | Note Added: 0010143 | |
| 2016-02-17 02:00 | Florian Dold | Note Added: 0010144 | |
| 2016-02-17 02:11 | Florian Dold | Note Added: 0010145 | |
| 2016-02-17 02:27 | Florian Dold | Note Added: 0010146 | |
| 2016-02-17 03:06 | Florian Dold | Note Added: 0010147 | |
| 2016-02-17 03:11 | Florian Dold | Status | assigned => resolved |
| 2016-02-17 03:11 | Florian Dold | Resolution | open => fixed |
| 2016-02-17 03:11 | Florian Dold | Assigned To | Marcello Stanisci => Florian Dold |
| 2016-02-17 16:34 | Christian Grothoff | Product Version | => 0.0 |
| 2016-02-17 16:34 | Christian Grothoff | Fixed in Version | => 0.0 |
| 2016-02-17 16:34 | Christian Grothoff | Target Version | => 0.0 |
| 2016-02-17 16:35 | Christian Grothoff | Status | resolved => closed |
| 2021-09-02 18:22 | Florian Dold | Changeset attached | => Taler-merchant master 75a01337 |
