I am trying to compile binutils to set up GNU toolchain for cross compiling for ARM on linux x86 architecture.
For this, I downloaded the GNU toolchain from :
http://lejosrt.org/tuto/install-gnu-arm-toolchain-under-linux
This requires a script to be run to install and compile everything.
However, on running the script, following error occurs:
make[2]: Entering directory /home/GNU_Toolchain/src/binutils-2.20.51.0.1/libiberty'
rm -f ./libiberty.a pic/./libiberty.a
ar rc ./libiberty.a \
./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o
*** buffer overflow detected ***: ar terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0x40117df0]
/lib/i386-linux-gnu/libc.so.6(+0xe4cca)[0x40116cca]
/lib/i386-linux-gnu/libc.so.6(+0xe43c8)[0x401163c8]
/lib/i386-linux-gnu/libc.so.6(_IO_default_xsputn+0x95)[0x4009b7e5]
/lib/i386-linux-gnu/libc.so.6(_IO_padn+0xc8)[0x4008f598]
/lib/i386-linux-gnu/libc.so.6(_IO_vfprintf+0x1cd5)[0x40070e35]
/lib/i386-linux-gnu/libc.so.6(__vsprintf_chk+0xad)[0x4011647d]
/lib/i386-linux-gnu/libc.so.6(__sprintf_chk+0x2d)[0x401163bd]
ar[0x804ec04]
ar[0x8050d38]
ar[0x80585c2]
ar[0x804b452]
ar[0x804c3fd]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x40048e37]
ar[0x80494c1]
======= Memory map: ========
08048000-080b5000 r-xp 00000000 08:01 3940915 /usr/local/bin/ar
080b5000-080b6000 r--p 0006c000 08:01 3940915 /usr/local/bin/ar
080b6000-080b7000 rw-p 0006d000 08:01 3940915 /usr/local/bin/ar
080b7000-080bb000 rw-p 00000000 00:00 0
08efe000-08f9d000 rw-p 00000000 00:00 0 [heap]
40000000-4001c000 r-xp 00000000 08:01 3670837 /lib/i386-linux-gnu/ld-2.13.so
4001c000-4001d000 r--p 0001b000 08:01 3670837 /lib/i386-linux-gnu/ld-2.13.so
4001d000-4001e000 rw-p 0001c000 08:01 3670837 /lib/i386-linux-gnu/ld-2.13.so
4001e000-4001f000 r-xp 00000000 00:00 0 [vdso]
4001f000-40021000 rw-p 00000000 00:00 0
40021000-40022000 r--p 0065c000 08:01 3544340 /usr/lib/locale/locale-archive
40032000-4018c000 r-xp 00000000 08:01 3670850 /lib/i386-linux-gnu/libc-2.13.so
4018c000-4018d000 ---p 0015a000 08:01 3670850 /lib/i386-linux-gnu/libc-2.13.so
4018d000-4018f000 r--p 0015a000 08:01 3670850 /lib/i386-linux-gnu/libc-2.13.so
4018f000-40190000 rw-p 0015c000 08:01 3670850 /lib/i386-linux-gnu/libc-2.13.so
40190000-40195000 rw-p 00000000 00:00 0
40195000-40395000 r--p 00000000 08:01 3544340 /usr/lib/locale/locale-archive
403a6000-403c0000 r-xp 00000000 08:01 3670878 /lib/i386-linux-gnu/libgcc_s.so.1
403c0000-403c1000 r--p 00019000 08:01 3670878 /lib/i386-linux-gnu/libgcc_s.so.1
403c1000-403c2000 rw-p 0001a000 08:01 3670878 /lib/i386-linux-gnu/libgcc_s.so.1
bff19000-bff3b000 rw-p 00000000 00:00 0 [stack]
make[2]: *** [libiberty.a] Aborted
make[2]: *** Deleting filelibiberty.a'
make[2]: Leaving directory /home/GNU_Toolchain/src/binutils-2.20.51.0.1/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory/home/GNU_Toolchain/src/binutils-2.20.51.0.1'
make: * [all] Error 2
I tried upgrading binutils package but in vain.
Any ideas?
Thanks in advance.
If you want to just build it and ignore potential problems, put -D_FORTIFY_SOURCE=1 in with your CFLAGS. Since you're using make, it would look something like:
make CFLAGS="«other CFLAGS» -D_FORTIFY_SOURCE=1" «...»
Depending on your project, you could even supply this as a flag to the configure script.
When you build, you'll get a bunch of warnings about redefining this macro, but that's expected.
So what does this flag do? I'm no expert, but it's basically a new feature in recent versions of gcc/glibc that attempts to detect buffer overflows. The default level is "2" (AFAIK), which actually imposes some extra limits above and beyond what the standards dictate. Level "1" is a little less strict.
If you're pedantic, you might like to investigate exactly why your compiler is detecting a buffer overflow. It might be, for example, a call to snprintf where someone's forgotten about the NUL termination behaviour.
(Although: before you go to the trouble, it's quite likely that it's been patched by someone in the upstream project and the fix hasn't trickled through to whatever project you're obtaining this from, so I'd ask the project maintainers about it first.)
For more information, see this RedHat binutils mailing list post.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 days ago.
Improve this question
`
Blockquote
``
'7fd50d583000-7fd50d67c000 r--p 002bd000 103:03 11700471 /home/sofiia/.rvm/rubies/ruby-2.7.2/lib/libruby.so.2.7.27fd50d67c000-7fd50d682000 r--p 003b5000 103:03 11700471 /home/sofiia/.rvm/rubies/ruby-2.7.2/lib/libruby.so.2.7.27fd50d682000-7fd50d685000 rw-p 003bb000 103:03 11700471 /home/sofiia/.rvm/rubies/ruby-2.7.2/lib/libruby.so.2.7.27fd50d685000-7fd50d6a2000 rw-p 00000000 00:00 07fd50d6a2000-7fd50d6a4000 r--p 00000000 103:03 25040902 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.27fd50d6a4000-7fd50d6ce000 r-xp 00002000 103:03 25040902 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.27fd50d6ce000-7fd50d6d9000 r--p 0002c000 103:03 25040902 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.27fd50d6d9000-7fd50d6da000 r-xp 00000000 00:00 07fd50d6da000-7fd50d6dc000 r--p 00037000 103:03 25040902 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.27fd50d6dc000-7fd50d6de000 rw-p 00039000 103:03 25040902 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.27ffcb3fcd000-7ffcb47cc000 rw-p 00000000 00:00 0 [stack]7ffcb47cf000-7ffcb47d3000 r--p 00000000 00:00 0 [vvar]7ffcb47d3000-7ffcb47d5000 r-xp 00000000 00:00 0 [vdso]ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
i have it answer when write create db
'
I've been trying to make the satellite tracker from the link below but when I run my code, I constantly get an error on the serial monitor.
https://github.com/CactusProjects/SatelliteTracker
I've tried to run the code on a Wemos D1 mini and NodeMCU V1.0 12-F, code uploaded with Arduino EDI 1.8.15
I've got all the libraries and the code compiles normally and uploads normally.
When running I get the following error in the serial monitor
Entering Setup
Entering Setup
No LSM303 (compass) detected.
Assuming Elevation is set to 20°
No Compass Present, Heading set to 0°
Compass Heading: 0.00°
Attempting to connect to WiFi
WiFi Connecting. . . 0
WiFi Connecting. . . 1
WiFi Connecting. . . 2
WiFi Connecting. . . 3
WiFi Connecting. . . 4
WiFi Connecting. . . 5
WiFi Connecting. . . 6
WiFi Connecting. . . 7
WiFi connected, IP address: 192.168.0.159
Today: 4
timeNow (unix timestamp): 1621490563
HTTP Request #0 is for ISS
Requesting URL: http://www.celestrak.com/satcat/tle.php?CATNR=25544
[HTTP] GET... code: 200
Recieved HTTP Payload for: ISS (ZARYA)
1 25544U 98067A 21140.04032925 .00001407 00000-0 33666-4 0 9993
2 25544 51.6437 121.9403 0003181 20.5176 89.9422 15.49024471284232
Back from getting TLE for: ISS
1 25544U 98067A 21140.04032925 .00001407 00000-0 33666-4 0 9993
2 25544 51.6437 121.9403 0003181 20.5176 89.9422 15.49024471284232
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Exception (0):
epc1=0x40205742 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
>>>stack>>>
ctx: cont
sp: 3ffffc60 end: 3fffffc0 offset: 0190
3ffffdf0: 3ffef0c8 3ffef0c8 00000000 40205742
3ffffe00: 4826f70a 40a58085 00000000 40201391
3ffffe10: 29694578 419c857d 53b4fc98 4188ba74
3ffffe20: 9e64e6bd 4142c36d 9f2847e7 4142c36d
3ffffe30: 9ec6536c 4142c36d 00000000 7ff80000
3ffffe40: 64c2e190 40243cd7 00000000 00000000
3ffffe50: 00000000 7ff80000 025b1a9d 40677d2c
3ffffe60: fd85cd34 4060ed36 e7c75dd0 4054b214
3ffffe70: 00000000 7ff80000 00000000 00000000
3ffffe80: 00000000 00000000 00000000 00000000
3ffffe90: 3ffef0c8 40768000 00000000 4020e35c
3ffffea0: 57b405d0 3fbf58d2 aa3f2101 3ffef4c8
3ffffeb0: 00000000 40768000 3ffef0c8 402051bf
3ffffec0: d2f1a9fc 3fb0624d 603dd1bb 4142c36d
3ffffed0: 3ffef100 00000005 3ffe8eec 40216020
3ffffee0: bd54dafd 40b819a8 6d8730c4 c0890ac4
3ffffef0: 8344ba4d c0a58087 b9e54e92 bfdace28
3fffff00: 4e957678 bfc08860 c6bf9100 407ac733
3fffff10: 603dd1bb 4142c36d 3ffef6d8 3ffef836
3fffff20: 3ffe85cc 00000045 3ffefbc8 3ffe85cc
3fffff30: 3ffef0c8 3ffef6ac 3ffef0c8 00000000
3fffff40: 3ffef0c8 3ffef6ac 3ffefbc8 402028a4
3fffff50: 00000000 40500000 feefeffe feefeffe
3fffff60: 00000000 0024002f 00000000 00000000
3fffff70: 0024002f 00000000 feefeffe feefeffe
3fffff80: 40496eb3 80000000 40160103 20000000
3fffff90: feefeffe feefeffe feefeffe 3ffefc58
3fffffa0: 3fffdad0 00000000 3ffefc44 40214730
3fffffb0: feefeffe feefeffe 3ffe87f8 40100e39
<<<stack<<<
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
After looking at the error in Arduino EDI "ESP Exception Decoder" I get the following error message but I am stuck at this point.
Exception 0: Illegal instruction
PC: 0x40205742
EXCVADDR: 0x00000000
Decoding stack results
0x40201391: Predict(int) at D:\Arduino Projects\tracker_main/tracker_main.ino line 408
0x4020e35c: Sgp4::visible() at D:\Arduino Projects\libraries\Sgp4-Library-master\src\visible.cpp line 197
0x402051bf: Sgp4::findsat(double) at D:\Arduino Projects\libraries\Sgp4-Library-master\src\sgp4pred.cpp line 87
0x40216020: uart_write(uart_t*, char const*, size_t) at C:\Users\Peter\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.0\cores\esp8266\uart.cpp line 546
0x402028a4: setup() at D:\Arduino Projects\tracker_main/tracker_main.ino line 157
0x40214730: loop_wrapper() at C:\Users\Peter\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.0\cores\esp8266\core_esp8266_main.cpp line 198
At the moment there is no hardware (sensors, stepper motor) connected to the NodeMCU, I only uploaded the code at first to see if I got this working.
I hope to find some help here.
So I've been following this blog to get my ruby on rails server setup. Everything has been great except for a few bugs here or there. However, when I run rake db:create I get this odd bug
ea000-76feb000 rw-p 00021000 b3:02 352 /lib/arm-linux-gnueabihf/ld-2.28.so
7e6a6000-7eea5000 rw-p 00000000 00:00 0 [stack]
7ef7a000-7ef7b000 r-xp 00000000 00:00 0 [sigpage]
7ef7b000-7ef7c000 r--p 00000000 00:00 0 [vvar]
7ef7c000-7ef7d000 r-xp 00000000 00:00 0 [vdso]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]
[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
ABORTED
I'm not quite sure what the bug is or why I can't see what the exact error is. The cli looks like the first 4 lines just repreated with various different foloders and no explanation
I use Ganglia to monitor Hadoop Flume Agents' performance. For almost 1 year now, it had been working very well. Last week gmetad started crashing with buffer overflow. Only thing that has changed in last few days is we started monitoring more instances of flume agent.
> gmond -V
gmond 3.7.2
> gmetad -V
gmetad 3.7.2
Below is the output I get when I run gmetad at command prompt with debug=100.
Please suggest how to overcome the buffer overflow problem.
Writing Summary data for source atl-ganglia, metric flume.SINK.hdfsSink.StartTime
Writing Summary data for source atl-ganglia, metric flume.CHANNEL.fileChannel.ChannelFillPercentage
*** buffer overflow detected ***: /usr/sbin/gmetad terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f9899751597]
/lib64/libc.so.6(+0x100480)[0x7f989974f480]
/lib64/libc.so.6(+0xff8d9)[0x7f989974e8d9]
/lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x7f98996c3639]
/lib64/libc.so.6(_IO_vfprintf+0x41c0)[0x7f9899697190]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f989974e97d]
/lib64/libc.so.6(__sprintf_chk+0x7f)[0x7f989974e8bf]
/usr/sbin/gmetad[0x40a714]
/usr/sbin/gmetad[0x40841f]
/usr/lib64/libganglia.so.0(hash_foreach+0x59)[0x7f989af731f9]
/usr/sbin/gmetad[0x408151]
/lib64/libexpat.so.1(+0xa836)[0x7f9899e16836]
/lib64/libexpat.so.1(+0xbbce)[0x7f9899e17bce]
/lib64/libexpat.so.1(+0xd4fa)[0x7f9899e194fa]
/lib64/libexpat.so.1(+0xde3b)[0x7f9899e19e3b]
/lib64/libexpat.so.1(XML_ParseBuffer+0x6d)[0x7f9899e1288d]
/usr/sbin/gmetad[0x409ddc]
/usr/sbin/gmetad[0x405116]
/lib64/libpthread.so.0(+0x7a51)[0x7f98999eaa51]
/lib64/libc.so.6(clone+0x6d)[0x7f989973796d]
======= Memory map: ========
00400000-00417000 r-xp 00000000 08:02 1077406 /usr/sbin/gmetad
00617000-00619000 rw-p 00017000 08:02 1077406 /usr/sbin/gmetad
00619000-0061a000 rw-p 00000000 00:00 0
0157e000-0159f000 rw-p 00000000 00:00 0 [heap]
7f988c000000-7f988c116000 rw-p 00000000 00:00 0
7f988c116000-7f9890000000 ---p 00000000 00:00 0
7f9890f0f000-7f9890f25000 r-xp 00000000 08:02 1569794 /lib64/libgcc_s-4.4.7-20120601.so.1
7f9890f25000-7f9891124000 ---p 00016000 08:02 1569794 /lib64/libgcc_s-4.4.7-20120601.so.1
.
.
.
7f989817f000-7f989837e000 ---p 00003000 08:02 1569886 /lib64/libgmodule-2.0.so.0.2800.8
7f989837e000-7f989837f000 rw-p 00002000 08:02 1569886 /lib64/libgmodule-2.0.so.0.2800.8/bin/bash: line 1: 19584 Aborted /usr/sbin/gmetad
[FAILED]
Looks like the format of performance numbers sent in XML formatted string by Flume to Ganglia is different when the Flume agent run on Linux vs Windows.
From Linux based Flume agent, the numbers are formatted as Float, whereas from Windows, the float comes further formatted in scientific notation.
This is from CentOs based Flume agent:
<METRIC NAME="flume.CHANNEL.memoryChannel.ChannelFillPercentage" VAL=**"0.018000000000000002"** TYPE="float" UNITS="" TN="39" TMAX="60" DMAX="0" SLOPE="both">
This is from Windows based Flume agent:
<METRIC NAME="flume.CHANNEL.fileChannel.ChannelFillPercentage" VAL=**"1.7976931348623157E308"** TYPE="float" UNITS="" TN="0" TMAX="60" DMAX="0" SLOPE="both">
Seems that the Ganglia daemon gmetad parses the XML string but does try to convert the string to number before storing in rrds. That when the buffer overflow occurs.
I stopped sending data from Windows based flume agents and now Ganglia monitoring is stable. Now need to find how to monitor windows based agents.
I am working on a medical device running with windows XP embded. Recently a crash occured on the device when I was trying to access certain functionality in the device remotely. it generated minidump files and I am trying to analyse the cause of crash.
I completely new to windbg and trying to analyze the dump file. here is the output of the !analyze comand:
FAULTING_IP:
S14_RecorderManager!HcTask::hc_erase_rec_entry+73 [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\managers\recordermanager\hc_task.cpp # 1771]
6d040ef3 8991c4e30000 mov dword ptr [ecx+0E3C4h],edx
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 6d040ef3 (S14_RecorderManager!HcTask::hc_erase_rec_entry+0x00000073)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 0000e3c4
Attempt to write to address 0000e3c4
DEFAULT_BUCKET_ID: INVALID_POINTER_WRITE
PROCESS_NAME: s14_fwcontainer.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
EXCEPTION_PARAMETER1: 00000001
EXCEPTION_PARAMETER2: 0000e3c4
WRITE_ADDRESS: 0000e3c4
FOLLOWUP_IP:
S14_RecorderManager!HcTask::hc_erase_rec_entry+73 [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\managers\recordermanager\hc_task.cpp # 1771]
6d040ef3 8991c4e30000 mov dword ptr [ecx+0E3C4h],edx
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
FAULTING_THREAD: 00000964
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_WRITE
BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_WRITE
LAST_CONTROL_TRANSFER: from 6d04103c to 6d040ef3
STACK_TEXT:
0012f684 6d04103c 6d0a3e98 561b3efd 00a2a328 S14_RecorderManager!HcTask::hc_erase_rec_entry+0x73 [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\managers\recordermanager\hc_task.cpp # 1771]
0012f6ac 6d043302 6d0a3e98 09ce1ed8 09a86c68 S14_RecorderManager!HcTask::hc_remove_current_rec_entry+0x7c [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\managers\recordermanager\hc_task.cpp # 1849]
0012f6c0 6d04a129 09ce1ed8 561b3eb9 00000ecc S14_RecorderManager!HcTask::hc_cancel_remote_recording+0xc2 [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\managers\recordermanager\hc_task.cpp # 12599]
0012f804 100953eb 00000ecc 009ec7d8 00000054 S14_RecorderManager!Listen_Port_Svc_Handler::handle_input+0x1a9 [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\managers\recordermanager\network_task.cpp # 596]
0012f820 1009525e 09ce1ec0 00000ecc 0012f858 s14ace!ACE_WFMO_Reactor::upcall+0xbb [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\wfmo_reactor.cpp # 2212]
0012f888 100950c6 00000003 00000e38 00000004 s14ace!ACE_WFMO_Reactor::complex_dispatch_handler+0xce [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\wfmo_reactor.cpp # 2111]
0012f8a4 10094f7d 00000e38 00000964 00000000 s14ace!ACE_WFMO_Reactor::dispatch_handler+0xe6 [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\wfmo_reactor.cpp # 2018]
0012f8c8 10094ee6 00000003 00000001 009ec7d8 s14ace!ACE_WFMO_Reactor::dispatch_handles+0x5d [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\wfmo_reactor.cpp # 1971]
0012f8dc 1004ba33 00000003 a9715800 00000001 s14ace!ACE_WFMO_Reactor::dispatch+0x36 [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\wfmo_reactor.cpp # 1927]
0012f918 10094bcd 00000003 a9715830 00000001 s14ace!ACE_WFMO_Reactor::safe_dispatch+0x53 [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\wfmo_reactor.inl # 965]
0012f984 78729882 0012f99c 1004b7f3 00000000 s14ace!ACE_WFMO_Reactor::event_handling+0x12d [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\wfmo_reactor.cpp # 1721]
0012f99c 1006ba1c 00000000 642f20b0 642f1cc0 mfc100u!AFX_MAINTAIN_STATE2::~AFX_MAINTAIN_STATE2+0x1d
0012f9b4 10010349 1006b9d0 00403d69 ab8d2213 s14ace!ACE_Reactor::run_reactor_event_loop+0x2c [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\reactor.cpp # 220]
0012f9bc 00403d69 ab8d2213 004065dc 009dd848 s14ace!ACE_Reactor::run_event_loop+0x19 [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\reactor.inl # 27]
0012fe64 00404633 00000005 009d61c8 ab8d25a3 s14_fwcontainer!S14::FrameworkRuntimeContainer::run+0x1289 [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\container\frameworkruntime.cpp # 166]
0012fed8 0040476f 00000005 009d61c8 10057966 s14_fwcontainer!ace_wmain_i+0x163 [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\container\main.cpp # 47]
0012fee4 10057966 00000005 009d61c8 a9715fe0 s14_fwcontainer!ACE_Main::run_i+0xf [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\container\main.cpp # 38]
0012ff68 00403fce 0012ff7c 00000005 009d61c8 s14ace!ace_os_wmain_i+0xa6 [m:\rafuro00_thirdparty_ms_int\thirdparty\ace\ace\os_main.cpp # 72]
0012ff7c 00404d7e 00000005 009d61c8 009d6a48 s14_fwcontainer!wmain+0x1e [f:\jenkins_views\jvc_vg2.2_ci_a19545\infrastructure\framework\container\main.cpp # 38]
0012ffc0 7c817077 00000000 00000000 7ffdd000 s14_fwcontainer!__tmainCRTStartup+0x122 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c # 552]
0012fff0 00000000 00404e9f 00000000 00000000 kernel32!BaseProcessStart+0x23
STACK_COMMAND: ~0s; .ecxr ; kb
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: s14_recordermanager!HcTask::hc_erase_rec_entry+73
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: S14_RecorderManager
IMAGE_NAME: S14_RecorderManager.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 51424061
FAILURE_BUCKET_ID: INVALID_POINTER_WRITE_c0000005_S14_RecorderManager.dll!HcTask::hc_erase_rec_entry
BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_WRITE_s14_recordermanager!HcTask::hc_erase_rec_entry+73
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/s14_fwcontainer_exe/0_0_0_0/514232ba/S14_RecorderManager_dll/0_0_0_0/51424061/c0000005/00010ef3.htm?Retriage=1
Followup: MachineOwner
I could able understand that the code has failed in S14_RecorderManager module. Any input on this output to proceed further will be a great help.
Thanks in advance for any suggestion.