I run a server in ESP8266 which accept argument and value when you click the submit button in the webpage. after some iteration of clicking the submit button, the esp8266 crashes with the Exception of:
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Exception (29):
epc1=0x40205224 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
>>>stack>>>
ctx: cont
sp: 3ffffca0 end: 3fffffc0 offset: 0190
3ffffe30: 3fff1598 3fff1598 3ffffe80 4020521f
3ffffe40: 3fff6354 3ffffe98 3ffffe80 40217ef0
3ffffe50: 00000003 3ffffec0 3ffffe80 40217f20
3ffffe60: 3ffffe98 3ffffea4 3fff1588 3fff0da4
3ffffe70: 00000000 3ffffec0 00000005 402053a9
3ffffe80: 3fff631c 0029002f 00003a30 3fff6300
3ffffe90: 0029002f 800001da 3fff6354 0029002f
3ffffea0: 00000001 3fffbf5c 0005002f 00217d42
3ffffeb0: 00000001 3fff0dac 3ffffefc 4020cb24
3ffffec0: 3fff68b4 01da01df 00000000 fffffffe
3ffffed0: 00000000 3fffc6fc 00000000 3fff1c88
3ffffee0: 00000000 3fffdad0 40223278 00000000
3ffffef0: 3ffffefc 3fffff64 3fff0a00 40223428
3fffff00: 00000000 000003e8 3fffff60 03e87701
3fffff10: 402583d1 00000004 3fff0d58 4020171a
3fffff20: 40258677 00000004 3fff0d58 3fff0d5c
3fffff30: 00000000 4bc6a7f0 0189374b 00000000
3fffff40: 00000000 00000000 4bc6a7f0 00000000
3fffff50: 000e001a 00050008 4010051c 0001fc51
3fffff60: 00000000 6c80e048 4024c800 3ffe8514
3fffff70: 024bbda9 80000000 00000000 4010059d
3fffff80: 00000000 00000000 00000001 3fff1cc8
3fffff90: 3fffdad0 00000000 0001fc51 40211f35
3fffffa0: 3fffdad0 00000000 3fff1c88 40218fd4
3fffffb0: feefeffe feefeffe 3ffe899c 40100f45
<<<stack<<<
last failed alloc call: 4020521F(100)
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
For debugging: Free Heap is printed(runs every 2 seconds using millis) in the serial monitor by
Serial.println(ESP.getFreeHeap());
The submit button is sending the following argument and value(Partial only) :
http://192.168.4.1?user=1234&password=1234&data1=qwertyuiopasdfghjklzxcvbnm&data1=qwertyuiopasdfghjklzxcvbnm&data2=qwertyuiopasdfghjklzxcvbnm&data3=qwertyuiopasdfghjklzxcvbnm&data4=qwertyuiopasdfghjklzxcvbnm
as you can see the FreeHeap is going down until it reaches the minimum where ESP8266 can't handle.
Is there a way to refresh or reuse the heap without rebooting the Chip?
Is safeString can help to this problem ?
I'm a newbie in Linux driver Field.Now, I has just done with writing Linux driver and I'm testing the accuracy of the function of this driver. The goal of my driver is using FPGA card with CPU ARMv7 through PCIe communication and doing both encryption and decryption in this card. When I test my kernel module, I see this kernel panic. In my test case, I send multiple packets continuously to FPGA card to implement encryption/decryption. However, after doing several packets well, Linux kernel was crash. At first, I think that this kernel crash bug is related to allocating kernel memory and freeing this memory (kzalloc function and kfree function). May be memory allocated for some pointer does not be freed immediately. Can anyone suggests the cause and the solution for this kernel panic?
[ 532.593938] Unable to handle kernel NULL pointer dereference at virtual address 00000001
[ 532.602069] pgd = ecb8c000
[ 532.604780] [00000001] *pgd=2ca83831, *pte=00000000, *ppte=00000000
[532.611066] Internal error: Oops: 17 [#1] SMP ARM
[ 532.615777] Modules linked in: testcrypto(+) huy_crypto xdma ath9k ath9k_common pppoe ppp_async ath9k_hw ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_policy xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt compat sch_cake
[ 532.686456] act_connmark nf_conntrack sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred cryptodev nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb ip6_vti ip_vti xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_beet ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet ipcomp esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel mpls_iptunnel mpls_router mpls_gso xfrm_user xfrm_ipcomp af_key xfrm_algo algif_skcipher algif_hash af_alg sha512_generic md5 echainiv cbc authenc gpio_button_hotplug [last unloaded: testcrypto]
[ 532.748684] CPU: 0 PID: 5563 Comm: insmod Not tainted 4.14.176 #0
[ 532.754789] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 532.760721] task: ef3bde00 task.stack: ef182000
[ 532.765263] PC is at __kmalloc_track_caller+0x100/0x144
[ 532.770499] LR is at 0x89a5
[ 532.773297] pc : [<c01ee8b4>] lr : [<000089a5>] psr: 20000013
[ 532.779576] sp : ef183d98 ip : a0000013 fp : ffffee4b
[ 532.784811] r10: 00000009 r9 : 00008124 r8 : 00000002
[ 532.790046] r7 : 00000001 r6 : ecfe2a40 r5 : 014000c0 r4 : ef001e40
[ 532.796586] r3 : 00000000 r2 : ef7d6a34 r1 : 2ee8d000 r0 : 000089a6
[ 532.803128] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 532.810278] Control: 10c5387d Table: 2cb8c04a DAC: 00000051
[ 532.816035] Process insmod (pid: 5563, stack limit = 0xef182210)
[ 532.822054] Stack: (0xef183d98 to 0xef184000)
[ 532.826419] 3d80: 00000008 c024eb40
[ 532.834616] 3da0: ecfe24c0 00000124 00000002 c01c73b8 ec94b540 ef0181c0 ec94b540 c024eb40
[ 532.842812] 3dc0: 00000000 00000124 bf6780c8 ec94b540 c07088c8 ec94b540 00000124 bf6780c8
[ 532.851008] 3de0: 00000000 c024fcc8 00000000 c07088c8 ec94b540 c025173c 00000000 edfed95c
[ 532.859204] 3e00: ec94b540 c025207c 00001000 00000000 c07088c8 edfed95c 00000000 00000000
[ 532.867401] 3e20: edfed800 edfeda58 ec94b540 c0252a5c 00000000 00000000 c07e21ec c07e21d8
[ 532.875597] 3e40: 00000008 ef183f40 edfed800 edfeda34 edfeda70 0000002c 014000c0 bf678080
[ 532.883793] 3e60: c0a03c48 c0193a30 bf67808c 00007fff bf678080 c0191330 c0a5dce8 bf6780c8
[ 532.891990] 3e80: c0190a50 bf67808c c0702ce4 bf678170 c082dfd8 c07da244 c07da3a0 c0a03c48
[ 532.900186] 3ea0: c07da250 f1523fff ffe00000 ef0e8600 fffff000 c0a5dcc0 014002c0 00000011
[ 532.908382] 3ec0: 00000000 00000000 00000000 00000000 00000000 00000000 6e72656b 00006c65
[ 532.916578] 3ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 532.924774] 3f00: 00000000 00000000 00000000 00000000 00000000 c9929c40 00000080 00000fe4
[ 532.932970] 3f20: 00000000 00642ff4 f1523fe4 ffffe000 b6f74230 00000051 00000000 c0194110
[ 532.941166] 3f40: f1515bcc f1513000 00010fe4 f1523904 f1523748 f151f760 00004000 00004080
[ 532.949362] 3f60: 00000000 00000000 00000000 000036d0 00000029 0000002a 00000017 00000000
[ 532.957558] 3f80: 00000012 00000000 00000000 00000000 00000003 00000080 c01077a4 ef182000
[ 532.965755] 3fa0: 00000080 c01075a0 00000000 00000000 00632010 00010fe4 b6f74230 00000700
[ 532.973951] 3fc0: 00000000 00000000 00000003 00000080 00010fe4 00000000 00000020 00000000
[ 532.982148] 3fe0: beca6d1c beca6d00 00011d50 b6f2abac 60000010 00632010 00000000 00000000
[ 532.990350] [<c01ee8b4>] (__kmalloc_track_caller) from [<c01c73b8>] (kstrdup+0x30/0x54)
[ 532.998378] [<c01c73b8>] (kstrdup) from [<c024eb40>] (__kernfs_new_node+0x28/0x130)
[ 533.006055] [<c024eb40>] (__kernfs_new_node) from [<c024fcc8>] (kernfs_new_node+0x1c/0x38)
[ 533.014340] [<c024fcc8>] (kernfs_new_node) from [<c025173c>] (__kernfs_create_file+0x18/0xa4)
[ 533.022885] [<c025173c>] (__kernfs_create_file) from [<c025207c>] (sysfs_add_file_mode_ns+0x13c/0x194)
[ 533.032213] [<c025207c>] (sysfs_add_file_mode_ns) from [<c0252a5c>] (internal_create_group+0x194/0x2e8)
[ 533.041630] [<c0252a5c>] (internal_create_group) from [<c0193a30>] (load_module+0x1b74/0x2118)
[ 533.050262] [<c0193a30>] (load_module) from [<c0194110>] (SyS_init_module+0x13c/0x174)
[ 533.058201] [<c0194110>] (SyS_init_module) from [<c01075a0>] (ret_fast_syscall+0x0/0x54)
[ 533.066312] Code: ea00000f e121f00c eaffffd2 e5943014 (e7973003)
[ 533.072445] ---[ end trace bb93ca4b64a48f93 ]---
[ 533.079218] Kernel panic - not syncing: Fatal exception
[ 533.084457] CPU1: stopping
[ 533.087173] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.14.176 #0
[ 533.094497] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 533.100436] [<c010ecf8>] (unwind_backtrace) from [<c010a9b0>] (show_stack+0x10/0x14)
[ 533.108202] [<c010a9b0>] (show_stack) from [<c0636974>] (dump_stack+0x94/0xa8)
[ 533.115442] [<c0636974>] (dump_stack) from [<c010db38>] (handle_IPI+0xe4/0x190)
[ 533.122769] [<c010db38>] (handle_IPI) from [<c0101494>] (gic_handle_irq+0x8c/0x90)
[ 533.130357] [<c0101494>] (gic_handle_irq) from [<c010b64c>] (__irq_svc+0x6c/0x90)
[ 533.137855] Exception stack(0xef067f80 to 0xef067fc8)
[ 533.142919] 7f80: 00000001 00000000 00000000 c01145a0 ffffe000 c0a03cb8 c0a03c6c 00000000
[ 533.151115] 7fa0: 00000000 414fc091 00000000 00000000 ef067fc8 ef067fd0 c0107f68 c0107f6c
[ 533.159309] 7fc0: 60000013 ffffffff
[ 533.162807] [<c010b64c>] (__irq_svc) from [<c0107f6c>] (arch_cpu_idle+0x34/0x38)
[ 533.170224] [<c0107f6c>] (arch_cpu_idle) from [<c015f6d4>] (do_idle+0xdc/0x19c)
[ 533.177551] [<c015f6d4>] (do_idle) from [<c015f9f0>] (cpu_startup_entry+0x18/0x1c)
[ 533.185139] [<c015f9f0>] (cpu_startup_entry) from [<0010182c>] (0x10182c)
[ 533.193813] Rebooting in 3 seconds..
(Updated)
Moreover, the kernel has been crashed after several packets processed. In the log, I see some bug information related to Insmod function. Here is my code in the Init function module: ( In my Init function, I implement encryption/decryption with one packet request many times by using a loop for and module_param value. )
static int __init test_init(void)
{
for (i = 0; i < req_num; i ++)
{
if (cipher_choice == 3)
{
test_esp_rfc4106(test_choice,endec);
mdelay(1000);
pr_err("--------------------------%d-------------------:
%s - PID:%d\n",__LINE__ , __func__ , current->pid);
pr_err("------------------------Number of req-----------
--------: %d\n",i);
}
}
return 0;
}
You can tell from the log that this happened right at soon as the module was loaded (well, during loading) because insmod is still running. It was creating an entry in '/sys'. This gives you some idea what may have been happening before the crash.
Since the crash is inside kstrdup/kmalloc and not directly related to your code, the most likely cause is either a double free or a buffer overflow in your module's code. Since it was soon after loading the module, probably the problem is in your module's init. No one is going to be able to tell you exactly what went wrong because you didn't post any code.
My app was retargeted from WP8.0 to WP Silverlight 8.1. Everything runs well no matter Debug/Release mode when I deployed from Visual Studio 2013 to WP8.1 Device. However, when I packed into xap format file and deployed by MS Deployment Tool, the app crash immediately after clicking even no slashscreen.
No too many document found about this on Internet. I am stunked here since 2 weeks. Hope any WP expert could do me a favor, please. Belows is WPA's analysing result of crash dump file if it could help :
**Exception Analysis Result**
SYMSRV: C:\SymCache\KERNELBASE.dll\54742BACbc000\KERNELBASE.dll not found
SYMSRV: C:\SymCache\KERNELBASE.dll\54742BACbc000\KERNELBASE.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/KERNELBASE.dll/54742BACbc000/KERNELBASE.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/KERNELBASE.dll/54742BACbc000/KERNELBASE.dll not found
FAULTING_IP:
KERNELBASE!RaiseException+37
777c35d6 b015 add sp,sp,#0x54
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 777c35d7 (KERNELBASE!RaiseException+0x00000037)
ExceptionCode: e0464645
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 88000837
CONTEXT: 00000000 -- (.cxr 0x0;r)
r0=000005f4 r1=00020000 r2=0141eb60 r3=00000000 r4=778c2451 r5=00000000
r6=00020000 r7=0141ea48 r8=00000568 r9=0141eb60 r10=0141eb60 r11=0141eb10
r12=00000087 sp=0141ea18 lr=761d40e7 pc=778c2456 psr=00000030 ----- Thumb
ntdll!NtAlpcSendWaitReceivePort+0x6:
778c2456 4770 bx lr {errorhandlingext!CheckForReadOnlyResourceFilter+0x2fa (761d40e6)}
DEFAULT_BUCKET_ID: WRONG_SYMBOLS
PROCESS_NAME: aghost.exe
ERROR_CODE: (NTSTATUS) 0xe0464645 - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xe0464645 - <Unable to get error code text>
EXCEPTION_PARAMETER1: 88000837
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: aghost.exe
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre
MANAGED_STACK: !dumpstack -EE
No export dumpstack found
MANAGED_BITNESS_MISMATCH:
Managed code needs matching platform of sos.dll for proper analysis. Use 'arm or x86' debugger.
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
LAST_CONTROL_TRANSFER: from 6e42fa46 to 777c35d6
STACK_TEXT:
0141fa68 6e42fa46 : e0464645 00000001 00000000 777c35d7 : KERNELBASE!RaiseException+0x36
0141fac8 6e440410 : 00000001 00000002 04fc4f98 00c83380 : npctrl!CXcpControl::CPReportError+0x66
0141faf8 6e41608e : 00c83380 00c83290 0141fb28 6e41608f : npctrl!CXcpControl::ReportError+0x10
0141fb08 6e411726 : 04fc4f98 00c83290 00000000 00000401 : npctrl!CXcpDispatcher::OnError+0xc2
0141fb30 6e3fe396 : 00000000 00000401 00000000 00c83290 : npctrl!CXcpDispatcher::OnWindowMessage+0x1275e
0141fb50 76669ce6 : 00c74858 7fd7b000 00c74858 00c603c8 : npctrl!CXcpDispatcher::GroupDispatchProcStatic+0x11e
0141fb80 76669d1e : 8000ffff 00c603c8 6e3fe279 0141fc90 : CoreMessaging!CoreUIConfigureTestHost+0x14aca
0141fbb8 7666672e : 0187bd20 766638d5 0141fc30 7666672f : CoreMessaging!CoreUIConfigureTestHost+0x14b02
0141fbc8 7666a346 : 00000000 00000000 00000000 7666a593 : CoreMessaging!CoreUIConfigureTestHost+0x11512
0141fc38 7666b322 : 0187b118 766ac010 0141fcc8 76664ca3 : CoreMessaging!CoreUIConfigureTestHost+0x1512a
0141fc70 766f396c : 00c38db0 0187b118 00000000 00000000 : CoreMessaging!CoreUIConfigureTestHost+0x16106
0141fcd0 766f3808 : 00000000 00000000 8000ffff 00c49740 : minuser!Core::Yield::IMessageLoopExtensions_Run+0x124
0141fd18 766e74b4 : fffffffe fffffffe 00bf0d40 00bf21d0 : minuser!Core::CoreUIAdapter::DispatchEvents+0x90
0141fd40 69ad81ac : 00000000 0141fdc0 00000000 777731c0 : minuser!minPeekMessageW+0x318
0141fdb0 69ad80c2 : 00000001 00000006 0141fe00 00000001 : windows_ui!Windows::UI::Core::CDispatcher::WaitAndProcessMessages+0xdc
0141fe58 00a324ee : 155bf757 00000002 00000001 00c38000 : windows_ui!Windows::UI::Core::CDispatcher::ProcessEvents+0x62
0141fec0 757a24ca : 00c58c08 00c49288 0141fed8 757a24cb : aghost+0x24ee
0141fed0 757a239a : 757a24a5 757d600c 0141ff08 757a239b : twinapi_appcore!Windows::ApplicationModel::Core::CoreApplicationView::Run+0x26
0141fee0 75fdff88 : 0141fef0 00c37fe0 00c325f0 00c37fe0 : twinapi_appcore!CWrlLightweightHandlerBase::ReleaseMarshalData+0x11a
0141ff10 77906426 : 00000000 00b3f740 00000000 00000000 : shcore!SHCreateThreadRef+0x200
0141ffa0 00000000 : 00000000 77906411 00000000 00000000 : ntdll!RtlUserThreadStart+0x16
STACK_COMMAND: ~4s; .ecxr ; kb
FOLLOWUP_IP:
npctrl!CXcpControl::CPReportError+66
6e42fa46 9b02 ldr r3,[sp,#8]
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: npctrl!CXcpControl::CPReportError+66
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: npctrl
IMAGE_NAME: npctrl.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: WRONG_SYMBOLS_e0464645_npctrl.dll!CXcpControl::CPReportError
BUCKET_ID: ARM_APPLICATION_FAULT_WRONG_SYMBOLS_npctrl!CXcpControl::CPReportError+66
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:wrong_symbols_e0464645_npctrl.dll!cxcpcontrol::cpreporterror
FAILURE_ID_HASH: {e963f9cc-8423-eaea-1bb2-e08acc6d433a}
I'm trying to understand where exactly does the executable assembly of a program end up, when a program is loaded/running. I found two resources talking about this, but they are somewhat difficult to read:
Understanding ELF using readelf and objdump Linux article (code formatting is messed up)
Michael Guyver, Some Assembly Required*: Relocations, Relocations (lots of assembly which I'm not exactly proficient in)
So, here's a brief example; I'm interested where does the executable section of the tail program end up. Basically, objdump tells me this:
$ objdump -dj .text /usr/bin/tail | head -10
/usr/bin/tail: file format elf32-i386
Disassembly of section .text:
08049100 <.text>:
8049100: 31 ed xor %ebp,%ebp
8049102: 5e pop %esi
8049103: 89 e1 mov %esp,%ecx
...
I'm assuming I'd see calls to tail's 'main()' be made here, had symbols not been stripped. Anyways, the start of the executable section is, according to this, 0x08049100; I'm interested in where it ends up eventually.
Then, I run tail in the background, getting its pid:
$ /usr/bin/tail -f & echo $!
28803
... and I inspect its /proc/pid/maps:
$ cat /proc/28803/maps
00547000-006a8000 r-xp 00000000 08:05 3506 /lib/i386-linux-gnu/libc-2.13.so
...
008c6000-008c7000 r-xp 00000000 00:00 0 [vdso]
08048000-08054000 r-xp 00000000 08:05 131469 /usr/bin/tail
08054000-08055000 r--p 0000b000 08:05 131469 /usr/bin/tail
08055000-08056000 rw-p 0000c000 08:05 131469 /usr/bin/tail
08af1000-08b12000 rw-p 00000000 00:00 0 [heap]
b76de000-b78de000 r--p 00000000 08:05 139793 /usr/lib/locale/locale-archive
...
bf845000-bf866000 rw-p 00000000 00:00 0 [stack]
Now I have tail three times - but the executable segment r-xp (which is the .text?) is apparently at 0x08048000 (an address that apparently was standardized back with SYSV for x86; also see Anatomy of a Program in Memory : Gustavo Duarte for an image)
Using the gnuplot script below, I arrived at this image:
First (topmost) plot shows "File offset" of sections from objdump (starts from 0x0); middle plot shows "VMA" (virtual memory address) of sections from objdump and bottom plot shows layout from /proc/pid/maps - both of these starting from 0x08048000; all three plots show the same range.
Comparing topmost and middle plot, it seems that the sections are more-less translated "as is" from the executable file to the VMA addresses (apart from the end); such that the whole executable file (not just .text section) starts from 0x08048000.
But comparing middle and bottom plot, it seems that when a program is running in memory, then only .text is "pushed back" to 0x08048000 - and not only that, it now appears larger!
The only explanation I have so far, is what I read somewhere (but lost the link): that an image in memory would have to have allocated a whole number of pages (of size e.g. 4096 bytes), and start from a page boundary. The whole number of pages explains the larger size - but, given that all these are virtual addresses, why the need to "snap" them to a page boundary (could one not, just as well, map the virtual address as is to a physical page boundary?)
So - could someone provide an explanation so as to why /proc/pid/maps sees the .text section in a different virtual address region from objdump?
mem.gp gnuplot script:
#!/usr/bin/env gnuplot
set term wxt size 800,500
exec = "/usr/bin/tail" ;
# cannot do - apparently gnuplot waits for children to exit, so locks here:
#runcmd = "bash -c '" . exec . " -f & echo $!'"
#print runcmd
#pid = system(runcmd) ;
#print runcmd, "pid", pid
# run tail -f & echo $! in another shell; then enter pid here:
pid = 28803
# $1 Idx $2 Name $3 Size $4 VMA $5 LMA $6 File off
cmdvma = "<objdump -h ".exec." | awk '$1 ~ \"^[0-9]+$\" && $2 !~ \".gnu_debuglink\" {print $1, $2, \"0X\"$3, \"0X\"$4;}'" ;
cmdfo = "<objdump -h ".exec." | awk '$1 ~ \"^[0-9]+$\" && $2 !~ \".gnu_debuglink\" {print $1, $2, \"0X\"$3, \"0X\"$6;}'" ;
cmdmaps = "<cat /proc/".pid."/maps | awk '{split($1,a,\"-\");b1=strtonum(\"0x\"a[1]);b2=strtonum(\"0x\"a[2]);printf(\"%d \\\"%s\\\" 0x%08X 0x%08X\\n\", NR,$6,b2-b1,b1);}'"
print cmdvma
print cmdfo
print cmdmaps
set format x "0x%08X" # "%016X";
set xtics rotate by -45 font ",7";
unset ytics
unset colorbox
set cbrange [0:25]
set yrange [0.5:1.5]
set macros
set multiplot layout 3,1 columnsfirst
# 0x08056000-0x08048000 = 0xe000
set xrange [0:0xe000]
set tmargin at screen 1
set bmargin at screen 0.667+0.1
plot \
cmdfo using 4:(1+$0*0.01):4:($4+$3):0 with xerrorbars lc palette t "File off", \
cmdfo using 4:(1):2 with labels font ",6" left rotate by -45 t ""
set xrange [0x08048000:0x08056000]
set tmargin at screen 0.667
set bmargin at screen 0.333+0.1
plot \
cmdvma using 4:(1+$0*0.01):4:($4+$3):0 with xerrorbars lc palette t "VMA", \
cmdvma using 4:(1):2 with labels font ",6" left rotate by -45 t ""
set tmargin at screen 0.333
set bmargin at screen 0+0.1
plot \
cmdmaps using 4:(1+$0*0.01):4:($4+$3):0 with xerrorbars lc palette t "/proc/pid/maps" , \
cmdmaps using 4:(1):2 with labels font ",6" left rotate by -45 t ""
unset multiplot
#system("killall -9 " . pid) ;
The short answer is that loadable segments get mapped into memory based on the ELF program headers with type PT_LOAD.
PT_LOAD - The array element specifies a loadable segment, described by
p_filesz and p_memsz. The bytes from the file are mapped to the
beginning of the memory segment. If the segment's memory size
(p_memsz) is larger than the file size (p_filesz), the ``extra'' bytes
are defined to hold the value 0 and to follow the segment's
initialized area. The file size may not be larger than the memory
size. Loadable segment entries in the program header table appear in
ascending order, sorted on the p_vaddr member.
For example, on my CentOS 6.4:
objdump -x `which tail`
Program Header:
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x0000e4d4 memsz 0x0000e4d4 flags r-x
LOAD off 0x0000e4d4 vaddr 0x080574d4 paddr 0x080574d4 align 2**12
filesz 0x000003b8 memsz 0x0000054c flags rw-
And from /proc/pid/maps:
cat /proc/2671/maps | grep `which tail`
08048000-08057000 r-xp 00000000 fd:00 133669 /usr/bin/tail
08057000-08058000 rw-p 0000e000 fd:00 133669 /usr/bin/tail
You will notice there is a difference between what maps and objdump says for the load address for subsequent sections, but that has to do with the loader accounting how much memory the section takes up as well as the alignment field. The first loadable segment is mapped in at 0x08048000 with a size of 0x0000e4d4, so you'd expect it to go from 0x08048000 to 0x080564d4, but the alignment says to align on 2^12 byte pages. If you do the math you end up at 0x8057000, matching /proc/pid/maps. So the second segment is mapped in at 0x8057000 and has a size of 0x0000054c (ending at 0x805754c), which is aligned to 0x8058000, matching /proc/pid/maps.
Thanks to the comment from #KerrekSB, I reread Understanding ELF using readelf and objdump - Linux article, and I think I sort of got it now (although it would be nice for someone else to confirm if its right).
Basically, the mistake is that the region 08048000-08054000 r-xp 00000000 08:05 131469 /usr/bin/tail from /proc/pid/maps does not start with .text section; and the missing link for knowing this is Program Header Table (PHT), as reported by readelf. Here is what it says for my tail:
$ readelf -l /usr/bin/tail
Elf file type is EXEC (Executable file)
Entry point 0x8049100
There are 9 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
[00] PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4
[01] INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
[02] LOAD 0x000000 0x08048000 0x08048000 0x0b9e8 0x0b9e8 R E 0x1000
[03] LOAD 0x00bf10 0x08054f10 0x08054f10 0x00220 0x003f0 RW 0x1000
[04] DYNAMIC 0x00bf24 0x08054f24 0x08054f24 0x000c8 0x000c8 RW 0x4
[05] NOTE 0x000168 0x08048168 0x08048168 0x00044 0x00044 R 0x4
[06] GNU_EH_FRAME 0x00b918 0x08053918 0x08053918 0x00024 0x00024 R 0x4
[07] GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
[08] GNU_RELRO 0x00bf10 0x08054f10 0x08054f10 0x000f0 0x000f0 R 0x1
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .eh_frame_hdr
07
08 .ctors .dtors .jcr .dynamic .got
I've added the [0x] line numbering in the "Program Headers:" section manually; otherwise it's hard to link it to Section to Segment mapping: below. Here also note: "Segment has many types, ... LOAD: The segment's content is loaded from the executable file. "Offset" denotes the offset of the file where the kernel should start reading the file's content. "FileSiz" tells us how many bytes must be read from the file. (Understanding ELF...)"
So, objdump tells us:
08049100 <.text>:
... that .text section starts at 0x08049100.
Then, readelf tells us:
[02] LOAD 0x000000 0x08048000 0x08048000 0x0b9e8 0x0b9e8 R E 0x1000
... that header/segment [02] is loaded from the executable file at offset zero into 0x08048000; and that this is marked R E - read and execute region of memory.
Further, readelf tells us:
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
... meaning that the header/segment [02] contains many sections - among them, also the .text; this now matches with the objdump view that .text starts higher than 0x08048000.
Finally, /proc/pid/maps of the running program tells us:
08048000-08054000 r-xp 00000000 08:05 131469 /usr/bin/tail
... that the executable (r-xp) "section" of the executable file is loaded at 0x08048000 - and now it is easy to see that this "section", as I called it, is called wrong - it is not a section (as per objdump nomenclature); but it is actually a "header/segment", as readelf sees it (in particular, the header/segment [02] we saw earlier).
Well, hopefully I got this right ( and hopefully someone can confirm if I did so or not :) )
The Deadlock occurs in my application when initialization of local static variable happens in the function called from DLLMain Entry point with param DLL_THREAD_DETACH.
Below is Windbg analysis
This is usually caused by another thread holding the loader lock.
Following are the Locks Held.
CritSec ntdll!LdrpLoaderLock+0 at 7c97e178
LockCount 3
RecursionCount 1
OwningThread 17e8
EntryCount d
ContentionCount d
*** Locked
CritSec MSVCR80!__app_type+94 at 781c3bc8
LockCount 1
RecursionCount 1
OwningThread 1100
EntryCount 1
ContentionCount 1
*** Locked
#
Call stack Thread 17e8
781c3bc8 78132bd9 0777fde4 ntdll!RtlEnterCriticalSection+0x46
00000008 b87d2630 00000000 MSVCR80!_lock+0x2e
0864ae10 08631d7f 0864ae10 EPComUtilities32!_onexit+0x36
0864ae10 b87d2588 00000001 EPComUtilities32!atexit+0x9
0777fea8 0864719f 08630000 EPComUtilities32!XCriticalSectionEx::ThreadTerminated+0x5f
08630000 00000003 00000000 EPComUtilities32!DllMain+0x20
08630000 7c90118a 08630000 EPComUtilities32!__DllMainCRTStartup+0x7a
08630000 00000003 00000000 EPComUtilities32!_DllMainCRTStartup+0x1d
#
Call Stack thread 1100
000000b0 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
000000b0 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
000000b0 ffffffff 06ce64e0 kernel32!WaitForSingleObject+0x12
000480ba 000f4240 00000000 CATSysMultiThreading!CATThreads::Join+0xf5
0012fcc8 00000004 00000000 JS0GROUP!CATLM::StopHB+0xf4
d138509f 00416694 00000001 JS0GROUP!CATLM::Unmake+0x6b
00000000 00000000 00000000 MSVCR80!_cinit+0xd6
00000000 0012fd6c 081e68d9 MSVCR80!exit+0xd
00000000 06d404f0 0998fb90 JS0GROUP!CATExit+0x1d
00000000 004ef366 0000000d DNBPLMProvider!DNBEPLMTransactionMgt::OnApplicationExit+0x229
00000000 0012fd9c 004eabfc JS0GROUP!CATCallExits+0x2bc
00000000 0012ff7c 0040cefd JS0GROUP!CATErrorNormalEnd+0x31
00000000 06ce71d0 06ce71d0 JS0GROUP!CATExit+0xc
00000007 06cdb120 059b61d8 DLMMfgContextSolver!main+0x146d
ffffffff ffffffff bffde000 DLMMfgContextSolver!__tmainCRTStartup+0x10f
#
Please give you comments to understand what might have caused the deadlock.
Note: the moment i make the static variable as non static the problem disappears this in context of example posted in forum Deadlock occurs in Function Scoped Static variables (Thread Unsafe in VC++)
In short, what caused the deadlock is that you did something non-trivial in DllMain.