Traceback on file from Westmoreland County

[GoogleCodeExporter]

AuditBear is giving a traceback on a file for Westmoreland County PA, May 2012. 
 Here is the traceback:

Traceback (most recent call last):
  File "/home/www-data/web2py/gluon/restricted.py", line 192, in restricted
    exec ccode in environment
  File "/home/www-data/web2py/applications/audit_bear/compiled/controllers_default_index.py", line 109, in <module>
  File "/home/www-data/web2py/gluon/globals.py", line 137, in <lambda>
    self._caller = lambda f: f()
  File "/home/www-data/web2py/applications/audit_bear/compiled/controllers_default_index.py", line 36, in index
  File "applications/audit_bear/modules/ballotImage.py", line 147, in __init__
    x = u[1]
IndexError: list index out of range

Looks like the error occurs when trying to parse a precinct number string.  
Maybe AuditBear found a string that it thought was a precinct number, and was 
expecting to contain ' - ', but didn't, so AuditBear got confused?  We should 
look into this, so they can use AuditBear.

Original issue reported on code.google.com by goo...@web.dwdw.me on 7 Jun 2013 at 7:16

[GoogleCodeExporter]

It looks like AuditBear is failing to extract precinct numbers correctly, from 
the EL155.LST.  Instead, it is getting the empty string.

Looking through the error report, it looks like at the point in execution where 
the IndexError was thrown (line 147 of ballotImage.py), m holds the value 
5156680, but machinePrecinctMap[m] is the empty string.  As a result, t and u 
become a list of length one, whose only element is the empty string.  So no 
surprise that line 147 blows up, given that we've reached this point.

But why is machinePrecinctMap messed up?  Here is its value at this point:

{'5102146': '', '5103772': '', '5104327': '', '5104390': '', '5104583': '', 
'5104673': '', '5104774': '', '5104853': '', '5104943': '', '5105087': '', ...}

In other words, AuditBear seems to have failed in parsing out precinct numbers.

Here are all the local variables and their values at the point where the 
traceback was thrown (line 147):

aLog: <applications.audit_bear.modules.auditLog.AuditLog instance>
c: '\x1bE\r'
currentPrecinct: ''
earlyVotingList: []
el68a: <applications.audit_bear.modules.el68a.EL68A instance>
electionID: '12GPWEST'
failsafeList: []
fh: <open file 
'/home/www-data/web2py/applications/audit_bear/uploads/pGpLlUz9G4', mode 'w+'>
file: <open file 
'/home/www-data/web2py/applications/audit_bear/uploads/pGpLlUz9G4', mode 'w+'>
l: '\x1bE\r'
list: []
m: '5156680'
machinePrecinctMap: {'5102146': '', '5103772': '', '5104327': '', '5104390': 
'', '5104583': '', '5104673': '', '5104774': '', '5104853': '', '5104943': '', 
'5105087': '', ...}
machinePrecinctNameMap: {}
machinePrecinctNumMap: {}
machineVotesMap: {'5102146': 1, '5103772': 60, '5104327': 67, '5104390': 96, 
'5104583': 71, '5104673': 58, '5104774': 75, '5104853': 117, '5104943': 63, 
'5105087': 49, ...}
newNameList: []
pCombinedMap: {}
pCurrentPrecinct: None
precinctMap: {}
precinctVotesMap: {'': 47191, '100 - ADAMSBURG BOROUGH': 17, '203 - ALLEGHENY 
TWP - NO 1': 467, '206 - ALLEGHENY TWP - NO 2': 136, '209 - ALLEGHENY TWP - NO 
3': 322, '212 - ALLEGHENY TWP - NO 4': 187, '215 - ALLEGHENY TWP - NO 5': 116, 
'311 - ARNOLD - 1-1': 52, '312 - ARNOLD - 1-2': 50, '321 - ARNOLD - 2-1': 106, 
...}
problemMap: {}
runDate: ''
s: ['\x1bE\r']
self: <applications.audit_bear.modules.ballotImage.BallotImage instance>
t: ['']
temp: 69
u: ['']
u2: ['']
voteCount: 50239
votes1: 0
votes2: 0
x: ''
y: ''

Original comment by goo...@web.dwdw.me on 7 Jun 2013 at 7:44

[GoogleCodeExporter]

Note especially the precinctVotesMap local variable, where AuditBear thinks 
that 47191 votes were cast in the precinct '' (empty string).  Looks like there 
must be a bug in the logic for extracting the precinct number.

Original comment by goo...@web.dwdw.me on 7 Jun 2013 at 7:47

[GoogleCodeExporter]

This issue was closed by revision r432.

Original comment by goo...@web.dwdw.me on 17 Jul 2013 at 4:19

• Changed state: Fixed

[GoogleCodeExporter]

Should be fixed in r432.  Thank you Annie!

Original comment by goo...@web.dwdw.me on 17 Jul 2013 at 4:59