View Issue Details

IDProjectCategoryView StatusLast Update
0005273Talerexchangepublic2018-04-15 20:35
ReporterFlorian DoldAssigned ToFlorian Dold 
PriorityhighSeveritycrashReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionSVN HEAD 
Target Version0.5Fixed in Version0.5 
Summary0005273: taler-exchange-wirewatch does not handle row id sizes correctly
Descriptionlast_row_off_size in taler-exchange-wirewatch is read but never written (it's static so initialized to zero).

This lead to the crash below, which we resolved for now by resetting the exchange database.
Steps To Reproducedemo-blue@tripwire:~$ taler-exchange-wirewatch -t test
Feb 05 15:20:16-401573 taler-exchange-wirewatch-17335 ERROR Assertion
failed at plugin_wire_test.c:958.
Feb 05 15:20:16-401685 taler-exchange-wirewatch-17335 ERROR Failed to
start request for account history!
TagsNo tags attached.

Activities

Christian Grothoff

2018-03-12 12:36

manager   ~0012883

Eh, I don't see this. It is intentionally left at 0 initially, unless get_latest_reserve_in_reference() succeeds. Overall, whenever we update "last_row_off", we also update last_row_off_size. There was one case on shutdown which did not reset last_row_off_size to 0 which I fixed.

I also found and removed a totally bogus GNUNET_break() in cb623d4..61fbc32.

Florian Dold

2018-03-12 13:00

manager   ~0012884

There was clearly something wrong in the old code, maybe you were looking at the wrong "original" version? See this:
https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-wirewatch.c?id=d126b166241e36a33884bc799190c708226ddb7e

The variable last_row_off_size was never written to in that file. And it's a static global, so it's *always* equal to zero, which certainly is not what you intended!

There was also some additional start_off, which made things more confusing (which AFAIK lead to some bug with the reset mode, I might misremember though).

(the GNUnet break you removed was bogus though!)

Christian Grothoff

2018-03-12 13:05

manager   ~0012885

Well, I see the issues in the old code, but regardless, the code right now looks fine, so clearly this bug should have been resolved, right?

Florian Dold

2018-03-12 13:06

manager   ~0012886

Yes, it should've been resolved!

Issue History

Date Modified Username Field Change
2018-02-05 16:26 Florian Dold New Issue
2018-02-05 16:26 Florian Dold Status new => assigned
2018-02-05 16:26 Florian Dold Assigned To => Christian Grothoff
2018-03-12 11:48 Christian Grothoff Product Version => SVN HEAD
2018-03-12 11:48 Christian Grothoff Target Version => 0.5
2018-03-12 12:36 Christian Grothoff Note Added: 0012883
2018-03-12 12:37 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2018-03-12 12:37 Christian Grothoff Status assigned => feedback
2018-03-12 13:00 Florian Dold Note Added: 0012884
2018-03-12 13:05 Christian Grothoff Note Added: 0012885
2018-03-12 13:06 Florian Dold Status feedback => resolved
2018-03-12 13:06 Florian Dold Resolution open => fixed
2018-03-12 13:06 Florian Dold Note Added: 0012886
2018-04-15 20:35 Christian Grothoff Fixed in Version => 0.5
2018-04-15 20:35 Christian Grothoff Status resolved => closed