|
I have seen assertion 108803 at two different locations in the same long-running I/O bound program in the past month. It goes away when the program is re-run. 2022 03 30 occurrence... 2022-03-30 16:21:59.205 DATA UPGRADE: Copying all of table 34 of 40: rroad_server_message 2022-03-30 16:22:08.505 DATA UPGRADE: Copying table 35 of 40: rroad_used_activation_key 2022-03-30 16:22:08.583 DATA UPGRADE: Step 2: Creating foreign keys and big indexes. *** ERROR *** Assertion failed: 108803 (17.0.9.4882) File pointer moved unexpectedly 2022 03 03 occurrence... I. 03/03 10:35:31. 2022-03-03 10:35:31.867 DATA UPGRADE: Copying all of table 32 of 40: rroad_sample_set I. 03/03 10:35:31. 2022-03-03 10:35:31.883 DATA UPGRADE: ...unloading table 32 to named pipe I. 03/03 10:35:31. 2022-03-03 10:35:31.883 DATA UPGRADE: ...loading table 32 from named pipe E. 03/03 10:35:33. *** ERROR *** Assertion failed: 108803 (17.0.9.4882) File pointer moved unexpectedly |
|
Curious. You asked so I'll (over-)explain it while I think this through for myself too :) That assertion is in code that is changing the size of a database file -- usually growing it but it might also be truncating the checkpoint log at shutdown. In your case, the failure means we successfully seeked to the position corresponding to the new size, told the OS make the file size match the current file location, verified that the current file position is still what we asked for, called SetFileValidData(), then asked for the current file position again. In your case, the file position has moved. It should not have. SetFileValidData() is a Windows API and it is an optimization which only works if you are running with administrative rights (it prevents the OS from writing zeroes to new sections of the file) so we don't care if it succeeds or fails. The server is going to initialize those pages anyway. SetFileValidData should not be moving the file pointer. If it did, I cannot account for it. Custom drivers maybe? Beta version of Windows? If SetFileValidData did not move the file pointer then probably only SQLAnywhere could have done it. The code I described above is the only piece of code in the server which uses the file pointer because the Windows API to set the file length requires it. If SQLAnywhere moved the file pointer, then it means another thread is adjusting the file size at the same time. This is, of course, supposed to be "impossible" because we protect against that. The assertion exists because if two threads are changing the size of the file at the same time then maybe we will truncate the file to the wrong length. I have never heard of this assertion being reported since it was added 12 years ago. Such a report would probably have come to me. If you have a repro, please open a case and report it. Otherwise, look for something unique about your environment: are you running uncommon hardware? Beta version of Windows? Oh, one last possibility: I've known virus scanners to interfere with OS calls and cause non-standard semantics. Perhaps a scanner is changing the file pointer when we call SetFileValidData. Check for an uncommon or recently updated virus scanner perhaps? Thanks very much! I don't know how to create a reproducible; in both occurrences, re-running the entire task worked. The hardware is an ordinary Dell workstation, somewhat aged, and the OS is an ordinary copy of Windows 10, somewhat lagging in terms of updates... no custom drivers etc. The task does grow the database: ALTER DBSPACE SYSTEM ADD 583176 PAGES The ALTER does take a while to run, but it finishes long before the assertion happens. The virus scanner is PC Matic Super Shield which works off a white list so it requires manual approval each time a new compile of the task is run... AFAIK after it gets approval it doesn't interfere further. BTW, the first occurrence was when a gigantic LOAD from named pipe was running, and the second was when a bunch of gigantic CREATE INDEX statements were running. After the first occurrence, I waved a dead chicken by removing the UNLOAD LOAD via named pipes technique, which slowed everything down but didn't stop the second occurrence. Should I wave another dead chicken, and try removing the ALTER?
(01 Apr '22, 09:42)
Breck Carter
Replies hidden
2
If the file needs to grow, the server needs to get into that code. If you remove the ALTER, the server will get into it more often due to small incremental growth. Even if the virus scanner works off of a whitelist it can still intercept calls and then decide not to do checking. For example, if the whitelist is based on a path prefix or pattern, it will intercept all calls, check the pattern and then either do checking for that instance of that call or not. I can think of these options:
(01 Apr '22, 10:48)
John Smirnios
> Even if the virus scanner works off of a whitelist it can still intercept calls. The whitelist identifies trusted executables... why would it bother intercepting calls? The point is moot, however... this executable is delivered to customers, and I have no control over what virus scanners they run.
(01 Apr '22, 15:54)
Breck Carter
|
