Hunting down a stack overflow crash in a WinCE 5.0 C++ application, narrowed it down to a
_stscanf( astring, _T("%*s %02d\n"), &aNumber );
call made on the end of a long chain of modal dialogs, with an value of _T("LEVEL 01").
Analyzing our exception handling stack frame logging and comparing stack pointer from the last stack frame stored vers. the SP at the point the exception was thrown seemed to show an insane amount of stack usage by _stscanf()....
...sufficiently insane that I felt I needed to verify it. After a couple of days of hacking I've come up with a test routine that performs high watermark type stack usage measurements for _stscanf().
We cross-compile for two different CE targets: CE 4.2 on Renesas/Hitachi SH4 and CE 5.0 on Freescale iMX32 (ARM1136 core), as well as a Desktop Windows Emulator.
Stack Usage for _stscanf() call (approx.):
Desktop 60
CE 4.2 on SH4 9252
CE 5.0 on ARM 9280
That's right, 9K of stack on CE?!!!??
Anyone else out there come across anything like this?
Found the culprit.
While I'd unsuccessfully checked for swscanf() source in my CE 4.2 Platform Builder install, CE 5.0 PB does have full source for the CRT.
Line 235 of C:\WINCE500\PRIVATE\WINCEOS\COREOS\CORE\CORELIBC\CRTW32\STDIO\input.c, an 8K buffer declared as a stack variable when compiled for a UNICODE system. The non-unicode equivalent gets by with a 32 byte buffer.
Related
We were using SCADA of Movicon 11.6 along with the Siemens 1200 PLC. Which was working fine since last three years. In last year the system were got formatted and all the softwares got uninstalled. We had the backup files of all programs, so we installed softwares again which we know and afterwards SCADA started working fine& communication with PLC also started. System is with windows 10 32 bit.
But the problem is, Reports are not getting open. Reports are loading, but after loading symbol it is showing 'Exception 80070057'in a popup screen with a title of Report filename.movbas
We are not aware which version of MS were used in the system. What will be cause. Can anyone support?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
**EventID 41
Version 8
Level 1
Task 63
Opcode 0
Keywords 0x8000400000000002
- TimeCreated
[ SystemTime] 2021-09-26T18:19:37.8668359Z
EventRecordID 1614
Correlation
- Execution
[ ProcessID] 4
[ ThreadID] 8
Channel System
Computer DESKTOP-IJTG7GS
- Security
[ UserID] S-1-5-18
- EventData
BugcheckCode 0
BugcheckParameter1 0x0
BugcheckParameter2 0x0
BugcheckParameter3 0x0
BugcheckParameter4 0x0
SleepInProgress 6
PowerButtonTimestamp 0
BootAppStatus 3221226017
Checkpoint 0
ConnectedStandbyInProgress false
SystemSleepTransitionsToOn 1
CsEntryScenarioInstanceId 0
BugcheckInfoFromEFI false
CheckpointStatus 0
CsEntryScenarioInstanceIdV2 0
LongPowerButtonPressDetected false**
So my computer restarts abruptly on it's own sometimes. I have tested ram and overheating issue but did not find any problem. I even installed windows again but the problem keeps on coming. Above is the event viewer critical error details. Please tell me what is the problem and how should i fix it. I am guessing it might be power supply. Just to be sure, what do you think it is.
My CPU is Intel(R) Xeon(R) CPU E3-1245 V2 # 3.40GHz 3.40 GHz it sits at 50 to 75 Celsius under load. normally its below 50. I have 20 gb ram and a 1050 ti. By the way i tested the pc after removing 1050 ti and placing quadro 4000 in it. But the problem did not solve. At one point computer would not even boot it kept on restarting at the booting screen. I don't know what to do...Help!?
Most probably it can be the PSU.
Windows Blue Screen of Death (BSOD) is a known windows error screen that appears now and then, randomly when some system drivers get corrupted, incompatible apps got installed, drivers outdated, etc. One such error is BSOD 0x8000400000000002. This error is related to kernel 41 critical error on Windows 10. And this is the same error you got. You can try:
Update the drivers: Open windows Device manager and from there you can update your drivers.
Turn off Fast Startup
Use a Restore Point, if you have one.
Unistall Recent Windows Update
Click on Start and open settings.
From settings, open Windows Update & Security option.
Then select “View Update History“
From the new page, click on “Uninstall Updates“.
Now, right-click on recently installed update and select Uninstall option.
Do uninstall all recent updates one by one and then restart your PC.
Update your BIOS
I'm trying to support 9-bit UART using Android Things,
When I try to set the data size to 9 I receive IO exception.
The only configurations that works are 7 and 8 bits.
I know that is possible to make 9-bit emulation using the parity error interrupt, but on android things, I don't receive any handler of it.
I tried also to set it using the native library, same exception.
Is there a chance to have this interrupt?
I'm using Pico-Pi iMX7D.
I don't understand why there is no high-level support of it.
Thank you in advance
Moved to feature request here: https://issuetracker.google.com/issues/67995082
I've recently discovered what appears to be a bug in Numexpr. Although I've already opened an issue on their Git hub, I figured I would avail myself of the collective wisdom here as well.
In a nutshell, evaluate sometimes (unpredictably) returns incorrect results when doing a straightforward array operation. The bug, which can be reproduced by the Python code below, results in a zero array being returned rather than the correct result. Although the sample code shows a multiplication, this bug has manifested for us on addition and exponentiation as well. Notably, there are no errors or warnings that are raised by Numexpr, the computational load appears normal (i.e. the RAM and CPU are taxed as expected when monitoring task manager), and the correct shape array is returned. It was a rather insidious bug to isolate for those reasons! In our tests, this bug has only manifested in the following hardware builds:
Windows Server 2012 r2, Intel Xeon 2680 v3,
2 processors, 48 logical cores
Windows 8.1, Intel Xeon 2690,
1 processor, 24 logical cores
In all the many thousands of runs of our software completed on our Windows 7, 64 bit, Intel i7 machines, this has never manifested. Furthermore, we have run the attached code many times (with bigger arrays and more iterations) and have not seen the error on the Windows 7, i7 machines. The Xeon computers, though, manifest it regularly. Unfortunately we don't have any other builds on which to test.
Other items of note:
We are running from the WinPython distribution 3.4.3.6.
We have not invoked any supporting Numexpr functions, just evaluate... so we are using its default settings.
The version of Numexpr is 2.4.4, as included in WinPython 3.4.3.6
Sample Code:
import numpy as np
import numexpr as ne
x = np.ones(1e6)
y = np.ones(1e6)
for ii in range(1000):
rr = ne.evaluate('x * y')
test = np.all(rr == 0)
if test:
print('Gotcha! %d' % ii)
print('Complete!')
When in release it crashes with an unhandled exception: std::length error.
The call stack looks like this:
msvcr90.dll!__set_flsgetvalue() Line 256 + 0xc bytes C
msvcr90.dll!__set_flsgetvalue() Line 256 + 0xc bytes C
msvcr90.dll!_getptd_noexit() Line 616 + 0x7 bytes C
msvcr90.dll!_getptd() Line 641 + 0x5 bytes C
msvcr90.dll!rand() Line 68 C
NEM.exe!CGAL::Random::Random() + 0x34 bytes C++
msvcr90.dll!_initterm(void (void)* * pfbegin=0x00000003, void (void)* * pfend=0x00345560) Line 903 C
NEM.exe!__tmainCRTStartup() Line 582 + 0x17 bytes C
kernel32.dll!7c817067()
Has anyone got any clues?
Examining the stack dump:
InitTerm is simply a function that walks a list of other functions and executes each in step - this is used for, amongst other things, global constructors (on startup), global destructors (on shutdown) and atexit lists (also on shutdown).
You are linking with CGAL, since that CGAL::Random::Random in your stack dump is due to the fact that CGAL defines a global variable called default_random of the CGAL::Random::Random type. That's why your error is happening before main, the default_random is being constructed.
From the CGAL source, all it does it call the standard C srand(time(NULL)) followed by the local get_int which, in turn, calls the standard C rand() to get a random number.
However, you're not getting to the second stage since your stack dump is still within srand().
It looks like it's converting your thread into a fiber lazily, i.e., this is the first time you've tried to do something in the thread and it has to set up fiber-local storage before continuing.
So, a couple of things to try and investigate.
1/ Are you running this code on pre-XP? I believe fiber-local storage (__set_flsgetvalue) was introduced in XP. This is a long shot but we need to clear it up anyway.
2/ Do you need to link with CGAL? I'm assuming your application needs something in the CGAL libraries, otherwise don't link with it. It may be a hangover from another project file.
3/ If you do use CGAL, make sure you're using the latest version. As of 3.3, it supports a dynamic linking which should prevent the possibility of mixing different library versions (both static/dynamic and debug/nondebug).
4/ Can you try to compile with VC8? The CGAL supported platforms do NOT yet include VC9 (VS2008). You may need to follow this up with the CGAL team itself to see if they're working on that support.
5/ And, finally, do you have Boost installed? That's another long shot but worth a look anyway.
If none of those suggestions help, you'll have to wait for someone more knowledgable than I to come along, I'm afraid.
Best of luck.
Crashes before main() are usually caused by a bad constructor in a global or static variable.
Looks like the constructor for class Random.
Do you have a global or static variable of type Random? Is it possible that you're trying to construct it before the library it's in has been properly initialized?
Note that the order of construction of global and static variables is not fixed and might change going from debug to release.
Could you be more specific about the error you're receiving? (unhandled exception std::length sounds weird - i've never heard of it)
To my knowledge, FlsGetValue automatically falls back to TLS counterpart if FLS API is not available.
If you're still stuck, take .dmp of your process at the time of crash and post it (use any of the numerous free upload services - and give us a link) (Sounds like a missing feature in SO - source/data file exchange?)