I am learning about the Linux user space memory layout on x86_64 systems and wanted to print some addresses from some of the sections. I used this Rust code:
fn main() {
let x = 3; // should be stored on stack
let s = "hello"; // should be in the .data section
println!("stack ≈ {:p}", &x);
println!(".text ≈ {:p}", main as *const ());
println!(".data ≈ {:p}", s);
use std::io;
let mut f = std::fs::File::open("/proc/self/maps").unwrap();
let out = io::stdout();
io::copy(&mut f, &mut out.lock()).unwrap();
}
This code also prints the file /proc/self/maps to stdout. I compiled this file mem.rs simply with rustc mem.rs. It printed:
stack ≈ 0x7ffffbf82f2c
.text ≈ 0x7f45b7c0a2b0
.data ≈ 0x7f45b7c4d35b
7f45b6800000-7f45b6c00000 rw-- 00000000 00:00 0
7f45b6de0000-7f45b6f9a000 r-x- 00000000 00:00 664435 /lib/x86_64-linux-gnu/libc-2.19.so
7f45b6f9a000-7f45b6fa2000 ---- 001ba000 00:00 664435 /lib/x86_64-linux-gnu/libc-2.19.so
[ ... more .so files]
7f45b7a22000-7f45b7a23000 r--- 00022000 00:00 663920 /lib/x86_64-linux-gnu/ld-2.19.so
7f45b7a23000-7f45b7a24000 rw-- 00023000 00:00 663920 /lib/x86_64-linux-gnu/ld-2.19.so
7f45b7a24000-7f45b7a25000 rw-- 00000000 00:00 0
7f45b7aa0000-7f45b7aa2000 rw-- 00000000 00:00 0
7f45b7ab0000-7f45b7ab2000 rw-- 00000000 00:00 0
7f45b7ac0000-7f45b7ac1000 rw-- 00000000 00:00 0
7f45b7ad0000-7f45b7ad1000 rw-- 00000000 00:00 0
7f45b7ae0000-7f45b7ae2000 rw-- 00000000 00:00 0
7f45b7c00000-7f45b7c5f000 r-x- 00000000 00:00 1134580 /home/lukas/tmp/mem
7f45b7e5e000-7f45b7e62000 r--- 0005e000 00:00 1134580 /home/lukas/tmp/mem
7f45b7e62000-7f45b7e63000 rw-- 00062000 00:00 1134580 /home/lukas/tmp/mem
7f45b7e63000-7f45b7e64000 rw-- 00000000 00:00 0
7ffffb784000-7ffffb785000 ---- 00000000 00:00 0 [stack]
7ffffb785000-7ffffbf84000 rw-- 00000000 00:00 0
7ffffc263000-7ffffc264000 r-x- 00000000 00:00 0 [vdso]
At least the addresses I printed on my own seem to match what maps says. But when I execute cat /proc/self/maps in the terminal, I get this output:
00400000-0040b000 r-x- 00000000 00:00 107117 /bin/cat
0060a000-0060b000 r--- 0000a000 00:00 107117 /bin/cat
0060b000-0060c000 rw-- 0000b000 00:00 107117 /bin/cat
0071c000-0073d000 rw-- 00000000 00:00 0 [heap]
7f7deb933000-7f7debc30000 r--- 00000000 00:00 758714 /usr/lib/locale/locale-archive
7f7debc30000-7f7debdea000 r-x- 00000000 00:00 664435 /lib/x86_64-linux-gnu/libc-2.19.so
7f7debdea000-7f7debdf2000 ---- 001ba000 00:00 664435 /lib/x86_64-linux-gnu/libc-2.19.so
[ ... more .so files ...]
7f7dec222000-7f7dec223000 r--- 00022000 00:00 663920 /lib/x86_64-linux-gnu/ld-2.19.so
7f7dec223000-7f7dec224000 rw-- 00023000 00:00 663920 /lib/x86_64-linux-gnu/ld-2.19.so
7f7dec224000-7f7dec225000 rw-- 00000000 00:00 0
7f7dec250000-7f7dec252000 rw-- 00000000 00:00 0
7f7dec260000-7f7dec261000 rw-- 00000000 00:00 0
7f7dec270000-7f7dec272000 rw-- 00000000 00:00 0
7ffff09e8000-7ffff11e8000 rw-- 00000000 00:00 0 [stack]
7ffff1689000-7ffff168a000 r-x- 00000000 00:00 0 [vdso]
The latter result matches everything I read about this topic: the sections from the executable are mapped in the lower end of the virtual address space (beginning around 0x400000).
I executed and compiled everything in the Linux Subsystem for Windows (Ubuntu 14.04 basically). I know, it's new and stuff, but I'm fairly sure this is not an issue with the subsystem (please tell me if it is, though!). Rust 1.14 is that matters (I doubt it),
I also tried the same with a C program (excuse my probably bad C):
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
int main(int argc, char **argv) {
FILE *test_file;
char buf[4096];
if ((test_file = fopen ("/proc/self/maps", "r")) != NULL) {
while (!feof (test_file)) {
fgets (buf, sizeof (buf), test_file);
puts (buf);
}
}
return 0;
}
It outputs something similar to cat:
00400000-00401000 r-x- 00000000 00:00 1325490 /home/lukas/tmp/a.out
00600000-00601000 r--- 00000000 00:00 1325490 /home/lukas/tmp/a.out
00601000-00602000 rw-- 00001000 00:00 1325490 /home/lukas/tmp/a.out
Why is the Rust executable mapped to large addresses near the stack?
Using rustc -Z print-link-args addr.rs, you can see what linker invocation the Rust compiler will use. Since the current linker happens to be cc, we can directly reuse these options for the C program. Ignoring unimportant arguments and removing others one-by-one, I was left with this compiler invocation:
gcc -fPIC -pie addr.c -o addr-c
Compiling the C code like this produces similar addresses as the Rust-compiled executable, indicating that one or both of those options is a likely culprit. This changes the question to "why does -fPIC and/or -pie map to such high addresses?"
I found another question and answer that seems to shed light on that:
The PIE binary is linked just as a shared library, and so its default load address (the .p_vaddr of the first LOAD segment) is zero. The expectation is that something will relocate this binary away from zero page, and load it at some random address.
Using readelf -e on the Rust executable, we can see that the first LOAD segment does have a virtual address of zero:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000005e6b4 0x000000000005e6b4 R E 200000
LOAD 0x000000000005ead0 0x000000000025ead0 0x000000000025ead0
0x00000000000039d1 0x00000000000049e8 RW 200000
I guess that this then changes the question to "why are these random addresses chosen", but I'm not sure of that answer. ^_^ A hunch tells me that ASLR comes into play. This other answer seems to bear that out:
PIE is to support ASLR in executable files.
ASLR is a security technique to help harden programs against certain types of attacks, so it makes sense that Rust, with its safety-minded approach, would attempt to enable something like this by default. Indeed, the addresses change a small bit each invocation:
root#97bcff9a925c:/# ./addr | grep 'r-xp' | grep 'addr'
5587cea9d000-5587ceafc000 r-xp 00000000 00:21 206 /addr
561d8aae2000-561d8ab41000 r-xp 00000000 00:21 206 /addr
555c30ffd000-555c3105c000 r-xp 00000000 00:21 206 /addr
55db249d5000-55db24a34000 r-xp 00000000 00:21 206 /addr
55e988572000-55e9885d1000 r-xp 00000000 00:21 206 /addr
560400e1b000-560400e7a000 r-xp 00000000 00:21 206 /addr
Test is on the 32 bit Linux
The code is as below:
int foo(int a, int b)
{
int c = a + b;
return c;
}
int main()
{
int e = 0;
int d = foo(1, 2);
printf("%d\n", d);
scanf("%d", &e);
return 0;
}
and when I use cat /proc/pid/maps to see the memory layout, it seems that I can see three
text segment for my code and the library.
ubuntu% cat /proc/2191/maps
08048000-08049000 r-xp 00000000 08:01 1467306 /home/shuai/work/asm/test1
08049000-0804a000 r--p 00000000 08:01 1467306 /home/shuai/work/asm/test1
0804a000-0804b000 rw-p 00001000 08:01 1467306 /home/shuai/work/asm/test1
09137000-09158000 rw-p 00000000 00:00 0 [heap]
b75c6000-b75c7000 rw-p 00000000 00:00 0
b75c7000-b776b000 r-xp 00000000 08:01 3149924 /lib/i386-linux-gnu/libc-2.15.so
b776b000-b776d000 r--p 001a4000 08:01 3149924 /lib/i386-linux-gnu/libc-2.15.so
b776d000-b776e000 rw-p 001a6000 08:01 3149924 /lib/i386-linux-gnu/libc-2.15.so
b776e000-b7771000 rw-p 00000000 00:00 0
b7780000-b7784000 rw-p 00000000 00:00 0
b7784000-b7785000 r-xp 00000000 00:00 0 [vdso]
b7785000-b77a5000 r-xp 00000000 08:01 3149914 /lib/i386-linux-gnu/ld-2.15.so
b77a5000-b77a6000 r--p 0001f000 08:01 3149914 /lib/i386-linux-gnu/ld-2.15.so
b77a6000-b77a7000 rw-p 00020000 08:01 3149914 /lib/i386-linux-gnu/ld-2.15.so
bfd47000-bfd68000 rw-p 00000000 00:00 0 [stack]
Could any one give me some guide about this issue? Thank you a lot!
Please mind the values in columns 3 (starting offset) and 2 (permissions). Really you have the same part mapped twice, in lines 1 and 2 for your binary file, but, in line 3, it's different. It's permitted to map the same file separately multiple times; different systems could skip merging this into one VM map entry, so it could reflect mapping history but not the current state jist.
If you see at library mappings you could easily find the law that any library is mapped separately:
With permission to read and execute: the main code which shouldn't be changed.
With permission to read: constant data area without code allowed.
With permission to read and write: it combines non-constant data area and relocation tables of shared objects.
Having the same starting 4K binary file area mapped twice could be explained with RTLD logic which differs from an arbitrary library logic due to bootstrapping needs. I don't treat it so important, more so it could easily differ on platform specifics.
Note that the three sections for each file have different permissions: read-only, read-write, and read-execute. This is for security: the code section (read-execute) can't be written to through exploits, and the segment that can be written can't be executed.
I'm trying to compile a vhdl file using xilinx's fuse (part of ISE) using a library I got from my university - pgm_pkg.vhd. The library is used to read the *.pgm image format into vhdl simulator. It works ok when simulated in Modelsim at windows, but unfortunately while compiling on debian using fuse it produces the following error:
*** glibc detected *** /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse: malloc(): memory corruption (fast): 0x00000000019c7780 ***
Using Modelsim (which is soo slow in student version) at virtual machine running windows (which makes it even slower) is something I would like to avoid at any cost.
I've narrowed the problem down to the function read_pgm_file() which iterates over the *.pgm file and provides the subsequent pixels of the image.
I've read that this kind of error is raised by gcc often many lines before the compilation crushes, but even that isn't helpful as fuse is a closed-source application. I've tried using different *.pgm pictures, I've also tried to compile it using verbose mode (I didn't find there anything helpful) and with the compilation multithreading off - still the same error occurs.
1) How do I handle such an error? Are there any tools for debugging during compilation?
2) What's wrong with the library? I can't see anything that could cause problems, especially that the same library works on windows very well.
The vhdl test file:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
USE work.pgm_pkg.ALL; -- read and write pgm format files package (max 512x512)
entity test_raw_tb is
GENERIC (
ifile : STRING := "pepper.ascii.pgm"
);
end test_raw_tb;
architecture behavioral of test_raw_tb is
constant infile : pgm_record_type := read_pgm_file(ifile);
begin -- architecture
end behavioral;
The pgm_pkg.vhd library:
PACKAGE pgm_pkg IS
constant max : NATURAL := 640;
constant pgm_row_size : integer :=18;
TYPE pixel_array_type IS ARRAY(0 TO max-1, 0 TO max - 1) OF integer;
TYPE pgm_record_type IS RECORD
magic_number : STRING(1 TO 2);
width : NATURAL;
height : NATURAL;
max_val : NATURAL;
pixel : pixel_array_type;
END RECORD;
IMPURE FUNCTION read_pgm_file(filename : IN STRING)
RETURN pgm_record_type;
IMPURE FUNCTION write_pgm_file(filename : IN STRING; pgm : pgm_record_type)
RETURN BOOLEAN;
IMPURE FUNCTION write_pgm_comment_file(filename : IN STRING; pgm : pgm_record_type)
RETURN BOOLEAN;
END pgm_pkg;
-----------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
library std;
use std.textio.all;
PACKAGE BODY pgm_pkg IS
IMPURE FUNCTION read_pgm_file(filename : IN STRING)
RETURN pgm_record_type IS
FILE filehandle : TEXT open read_mode is filename;
VARIABLE inline : LINE;
VARIABLE inline_copy : LINE;
VARIABLE char : CHARACTER;
VARIABLE good : BOOLEAN;
VARIABLE number : integer;
VARIABLE header_index : NATURAL;
VARIABLE magic_number : STRING(1 TO 2);
VARIABLE got_magic_number : BOOLEAN := FALSE;
VARIABLE width : NATURAL;
VARIABLE height : NATURAL;
VARIABLE max_val : NATURAL;
VARIABLE got_header : BOOLEAN;
VARIABLE pi,pj : NATURAL; -- pixel index
VARIABLE pgm : pgm_record_type;
BEGIN
got_magic_number := FALSE;
got_header := FALSE;
header_index := 0;
pi := 0; -- pixel index
pj := 0;
WHILE (NOT(ENDFILE(filehandle))) LOOP
READLINE(filehandle, inline);
-- make a copy of inline string for later (note it's an access type)
inline_copy := new STRING'(inline.ALL);
READ(inline, char, good);
-- move on to next line if it's a comment
NEXT WHEN char = '#';
-- special case for magic number
IF (got_magic_number = FALSE) THEN
ASSERT (char = 'P' OR char = 'p')
REPORT "Error: Not PGM format file. Magic number should start with P."
SEVERITY FAILURE;
READ(inline, char, good);
ASSERT (char = '2')
REPORT "Error: Not ASCII PGM format file. Magic number should be P2."
SEVERITY FAILURE;
pgm.magic_number(1) := 'P';
pgm.magic_number(2) := '2';
got_magic_number := TRUE;
-- strip off first two characters of inline_copy as they were magic_number
READ(inline_copy, char, good);
READ(inline_copy, char, good);
END IF;
IF (got_magic_number = TRUE) THEN
good := TRUE;
WHILE (inline_copy'LENGTH /= 0 AND good = TRUE) LOOP
READ(inline_copy, number, good);
IF (good = TRUE) THEN
IF (got_header = TRUE) THEN
pgm.pixel(pi,pj) := number;
pj := pj + 1;
if pj=pgm.width then
pj:=0;
pi:=pi+1;
end if;
ELSE
IF (header_index = 0) THEN -- it must be width
pgm.width := number;
header_index := 1; -- look for height next
ELSIF (header_index = 1) THEN -- it must be height
pgm.height := number;
header_index := 2; -- look for max_val next
ELSE -- it must be max_val
pgm.max_val := number;
got_header := TRUE;
END IF; -- header_index
END IF; -- got_header
END IF; -- good
END LOOP;
END IF; -- got_magic_number = TRUE
END LOOP; -- NOT ENDFILE
ASSERT got_header
REPORT "Error: Can't find header information - giving up."
SEVERITY FAILURE;
RETURN pgm;
END read_pgm_file;
-----------------------------------------------------------------------
IMPURE FUNCTION write_pgm_comment_file(filename : IN STRING;
pgm : pgm_record_type)
RETURN BOOLEAN IS
FILE filehandle : TEXT open write_mode is filename;
VARIABLE outline : LINE;
VARIABLE pi,pj : NATURAL; -- pixel index
VARIABLE k : NATURAL := 0;
CONSTANT row_comment : STRING := "# row ";
BEGIN
WRITE(outline, pgm.magic_number);
WRITELINE(filehandle, outline);
WRITE(outline, pgm.width);
WRITELINE(filehandle, outline);
WRITE(outline, pgm.height);
WRITELINE(filehandle, outline);
WRITE(outline, pgm.max_val);
WRITELINE(filehandle, outline);
pi := 0;
pj := 0;
k := 0;
wfile_i:
for pi in 0 to pgm.height-1 loop
write(outline, string'("# row "));
write(outline, pi, left, 5);
writeline(filehandle, outline);
wfile_j:
for pj in 0 to pgm.width-1 loop
write(outline,pgm.pixel(pi,pj),right,4);
if k < (pgm_row_size - 1) then
k:=k+1;
else
writeline(filehandle,outline);
k:=0;
end if;
end loop wfile_j;
k:=0;
writeline(filehandle,outline);
end loop wfile_i;
RETURN TRUE;
end write_pgm_comment_file;
-----------------------------------------------------------------------------
IMPURE FUNCTION write_pgm_file(filename : IN STRING;
pgm : pgm_record_type)
RETURN BOOLEAN IS
FILE filehandle : TEXT open write_mode is filename;
VARIABLE outline : LINE;
VARIABLE pi,pj : NATURAL; -- pixel index
VARIABLE k : NATURAL := 0;
BEGIN
WRITE(outline, pgm.magic_number);
WRITELINE(filehandle, outline);
WRITE(outline, pgm.width);
WRITE(outline, ' ');
WRITE(outline, pgm.height);
WRITELINE(filehandle, outline);
WRITE(outline, pgm.max_val);
WRITELINE(filehandle, outline);
pi := 0;
pj := 0;
k := 0;
wfile_i:
for pi in 0 to pgm.height-1 loop
wfile_j:
for pj in 0 to pgm.width-1 loop
write(outline,pgm.pixel(pi,pj),right,4);
if k < (pgm_row_size - 1) then
k:=k+1;
else
writeline(filehandle,outline);
k:=0;
end if;
end loop wfile_j;
k:=0;
writeline(filehandle,outline);
end loop wfile_i;
RETURN TRUE;
end write_pgm_file;
end pgm_pkg;
Compilation log:
Compilation of test_raw_tb.vhd...
Running: /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse -v 2 -mt off -o test_raw_tb.exe -prj test_raw_tb.prj test_raw_tb
ISim P.49d (signature 0xfbc00daa)
Turned off multi-threading for compilation
Determining compilation order of HDL files
--output trimmed--
Parsing VHDL file "pgm_pkg.vhd" into library work
Parsing VHDL file "test_raw_tb.vhd" into library work
Starting static elaboration
Executing test_raw_tb(behavioral)
*** glibc detected *** /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse: malloc(): memory corruption (fast): 0x00000000019c7780 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x76d76)[0x7f11af7c4d76]
/lib/x86_64-linux-gnu/libc.so.6(+0x7a658)[0x7f11af7c8658]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x70)[0x7f11af7c9b90]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libstlport.so.5.1(_Znwm+0x1d)[0x7f11b2b7909d]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libPortability.so(_ZN15Port_MsgManData12createObjectEPKcS1_iS1_+0x33)[0x7f11b286a043]
/opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse[0x5fe2ba]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x7f11b0180030]
/lib/x86_64-linux-gnu/libc.so.6(+0x1277fc)[0x7f11af8757fc]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific5Array6RemoveEjj+0x3a)[0x7f11b3748906]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific16VhdlSubprogramId24ElaboratePragmaProcedureEPKNS_5ArrayEPNS_12VhdlDataFlowE+0x145f)[0x7f11b3a2e295]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific16VhdlSubprogramId19ElaborateSubprogramEPNS_5ArrayEPNS_14VhdlConstraintEPNS_12VhdlDataFlowEPNS_12VhdlTreeNodeEPNS_9VhdlIdDefE+0xf3)[0x7f11b3a2e8b1]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific15VhdlIndexedName8EvaluateEPNS_14VhdlConstraintEPNS_12VhdlDataFlowEj+0x12b)[0x7f11b3a4cc81]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific26VhdlProcedureCallStatement9ElaborateEPNS_12VhdlDataFlowEPNS_22VhdlBlockConfigurationE+0x3e)[0x7f11b3a85c7a]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific15VhdlWhileScheme9ElaborateEPNS_9VhdlIdDefEPNS_5ArrayES4_PNS_22VhdlBlockConfigurationEPNS_12VhdlDataFlowE+0x2b3)[0x7f11b3a38867]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific17VhdlLoopStatement9ElaborateEPNS_12VhdlDataFlowEPNS_22VhdlBlockConfigurationE+0xfe)[0x7f11b3a85da8]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific15VhdlIfStatement13ElaborateCoreEPNS_12VhdlDataFlowE+0x24f)[0x7f11b3a88731]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific15VhdlIfStatement9ElaborateEPNS_12VhdlDataFlowEPNS_22VhdlBlockConfigurationE+0x52)[0x7f11b3a88e8a]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific15VhdlWhileScheme9ElaborateEPNS_9VhdlIdDefEPNS_5ArrayES4_PNS_22VhdlBlockConfigurationEPNS_12VhdlDataFlowE+0x2b3)[0x7f11b3a38867]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific17VhdlLoopStatement9ElaborateEPNS_12VhdlDataFlowEPNS_22VhdlBlockConfigurationE+0xfe)[0x7f11b3a85da8]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific18VhdlSubprogramBody19ElaborateSubprogramEPKNS_5ArrayEPNS_14VhdlConstraintEPNS_12VhdlDataFlowEPNS_12VhdlTreeNodeEjPNS_9VhdlIdDefE+0x1217)[0x7f11b3a10cdf]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific16VhdlSubprogramId19ElaborateSubprogramEPNS_5ArrayEPNS_14VhdlConstraintEPNS_12VhdlDataFlowEPNS_12VhdlTreeNodeEPNS_9VhdlIdDefE+0x1aa)[0x7f11b3a2e968]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific15VhdlIndexedName8EvaluateEPNS_14VhdlConstraintEPNS_12VhdlDataFlowEj+0x12b)[0x7f11b3a4cc81]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific16VhdlConstantDecl9ElaborateEPNS_12VhdlDataFlowE+0x8b)[0x7f11b3a0d7f1]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific20VhdlArchitectureBody15StaticElaborateEPNS_22VhdlBlockConfigurationE+0x9e)[0x7f11b3ac9c54]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific14VhdlEntityDecl23StaticElaborateInternalEPKcPNS_5ArrayES4_PNS_22VhdlBlockConfigurationEPNS_9VhdlIdDefE+0x3ff)[0x7f11b3ac91d1]
/opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(_ZN7Verific14VhdlEntityDecl15StaticElaborateEPKcPNS_5ArrayES4_PNS_22VhdlBlockConfigurationEPNS_9VhdlIdDefE+0x157)[0x7f11b3ac7f35]
/opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse(_ZN5ISIMC4Fuse15elaborateDesignEv+0x27a)[0x4550aa]
/opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse(_ZN5ISIMC4Fuse3runEv+0x117)[0x46aaf7]
/opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse(_ZN5ISIMC4Fuse4mainEiPPc+0x59)[0x46bcb9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f11af76cead]
/opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse(__gxx_personality_v0+0x209)[0x451c49]
======= Memory map: ========
00400000-006c0000 r-xp 00000000 08:05 1977591 /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse
008c0000-008c7000 rw-p 002c0000 08:05 1977591 /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse
008c7000-008c8000 rw-p 00000000 00:00 0
01602000-019cf000 rw-p 00000000 00:00 0 [heap]
7f11a8000000-7f11a8021000 rw-p 00000000 00:00 0
7f11a8021000-7f11ac000000 ---p 00000000 00:00 0
7f11aec42000-7f11aef92000 r-xp 00000000 08:05 1978523 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libxercesc.so
7f11aef92000-7f11af191000 ---p 00350000 08:05 1978523 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libxercesc.so
7f11af191000-7f11af1ce000 rw-p 0034f000 08:05 1978523 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libxercesc.so
7f11af1ce000-7f11af1cf000 rw-p 00000000 00:00 0
7f11af1cf000-7f11af22f000 r-xp 00000000 08:05 1978520 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libUtilC_MessageDispatcher.so
7f11af22f000-7f11af42f000 ---p 00060000 08:05 1978520 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libUtilC_MessageDispatcher.so
7f11af42f000-7f11af433000 rw-p 00060000 08:05 1978520 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libUtilC_MessageDispatcher.so
7f11af433000-7f11af449000 r-xp 00000000 08:05 1978531 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_zlib-gcc41-mt-p-1_38.so.1.38.0
7f11af449000-7f11af548000 ---p 00016000 08:05 1978531 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_zlib-gcc41-mt-p-1_38.so.1.38.0
7f11af548000-7f11af549000 rw-p 00015000 08:05 1978531 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_zlib-gcc41-mt-p-1_38.so.1.38.0
7f11af549000-7f11af54d000 r-xp 00000000 08:05 786505 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f11af54d000-7f11af74c000 ---p 00004000 08:05 786505 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f11af74c000-7f11af74d000 r--p 00003000 08:05 786505 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f11af74d000-7f11af74e000 rw-p 00004000 08:05 786505 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f11af74e000-7f11af8ce000 r-xp 00000000 08:05 786451 /lib/x86_64-linux-gnu/libc-2.13.so
7f11af8ce000-7f11aface000 ---p 00180000 08:05 786451 /lib/x86_64-linux-gnu/libc-2.13.so
7f11aface000-7f11afad2000 r--p 00180000 08:05 786451 /lib/x86_64-linux-gnu/libc-2.13.so
7f11afad2000-7f11afad3000 rw-p 00184000 08:05 786451 /lib/x86_64-linux-gnu/libc-2.13.so
7f11afad3000-7f11afad8000 rw-p 00000000 00:00 0
7f11afad8000-7f11afaed000 r-xp 00000000 08:05 786436 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f11afaed000-7f11afced000 ---p 00015000 08:05 786436 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f11afced000-7f11afcee000 rw-p 00015000 08:05 786436 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f11afcee000-7f11afd6f000 r-xp 00000000 08:05 786448 /lib/x86_64-linux-gnu/libm-2.13.so
7f11afd6f000-7f11aff6e000 ---p 00081000 08:05 786448 /lib/x86_64-linux-gnu/libm-2.13.so
7f11aff6e000-7f11aff6f000 r--p 00080000 08:05 786448 /lib/x86_64-linux-gnu/libm-2.13.so
7f11aff6f000-7f11aff70000 rw-p 00081000 08:05 786448 /lib/x86_64-linux-gnu/libm-2.13.so
7f11aff70000-7f11b0056000 r-xp 00000000 08:05 1983260 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libstdc++.so.6
7f11b0056000-7f11b0156000 ---p 000e6000 08:05 1983260 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libstdc++.so.6
7f11b0156000-7f11b0157000 r--p 000e6000 08:05 1983260 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libstdc++.so.6
7f11b0157000-7f11b015f000 rw-p 000e7000 08:05 1983260 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libstdc++.so.6
7f11b015f000-7f11b0171000 rw-p 00000000 00:00 0
7f11b0171000-7f11b0188000 r-xp 00000000 08:05 786441 /lib/x86_64-linux-gnu/libpthread-2.13.so
7f11b0188000-7f11b0387000 ---p 00017000 08:05 786441 /lib/x86_64-linux-gnu/libpthread-2.13.so
7f11b0387000-7f11b0388000 r--p 00016000 08:05 786441 /lib/x86_64-linux-gnu/libpthread-2.13.so
7f11b0388000-7f11b0389000 rw-p 00017000 08:05 786441 /lib/x86_64-linux-gnu/libpthread-2.13.so
7f11b0389000-7f11b038d000 rw-p 00000000 00:00 0
7f11b038d000-7f11b038f000 r-xp 00000000 08:05 786444 /lib/x86_64-linux-gnu/libdl-2.13.so
7f11b038f000-7f11b058f000 ---p 00002000 08:05 786444 /lib/x86_64-linux-gnu/libdl-2.13.so
7f11b058f000-7f11b0590000 r--p 00002000 08:05 786444 /lib/x86_64-linux-gnu/libdl-2.13.so
7f11b0590000-7f11b0591000 rw-p 00003000 08:05 786444 /lib/x86_64-linux-gnu/libdl-2.13.so
7f11b0591000-7f11b05df000 r-xp 00000000 08:05 1978522 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libUtilities.so
7f11b05df000-7f11b07de000 ---p 0004e000 08:05 1978522 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libUtilities.so
7f11b07de000-7f11b07e1000 rw-p 0004d000 08:05 1978522 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libUtilities.so
7f11b07e1000-7f11b07f2000 r-xp 00000000 08:05 1978515 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libStaticFileParsers.so
7f11b07f2000-7f11b09f2000 ---p 00011000 08:05 1978515 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libStaticFileParsers.so
7f11b09f2000-7f11b09f3000 rw-p 00011000 08:05 1978515 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libStaticFileParsers.so
7f11b09f3000-7f11b0a02000 r-xp 00000000 08:05 1978526 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_bzip2-gcc41-mt-p-1_38.so.1.38.0
7f11b0a02000-7f11b0b01000 ---p 0000f000 08:05 1978526 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_bzip2-gcc41-mt-p-1_38.so.1.38.0
7f11b0b01000-7f11b0b03000 rw-p 0000e000 08:05 1978526 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_bzip2-gcc41-mt-p-1_38.so.1.38.0
7f11b0b03000-7f11b0b04000 r-xp 00000000 08:05 1978009 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libCit_Core.so
7f11b0b04000-7f11b0d04000 ---p 00001000 08:05 1978009 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libCit_Core.so
7f11b0d04000-7f11b0d05000 rw-p 00001000 08:05 1978009 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libCit_Core.so
7f11b0d05000-7f11b0d8a000 r-xp 00000000 08:05 1978505 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libPersonalityModule.so
7f11b0d8a000-7f11b0f89000 ---p 00085000 08:05 1978505 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libPersonalityModule.so
7f11b0f89000-7f11b0f8e000 rw-p 00084000 08:05 1978505 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libPersonalityModule.so
7f11b0f8e000-7f11b0f9b000 r-xp 00000000 08:05 1978528 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_iostreams-gcc41-mt-p-1_38.so.1.38.0
7f11b0f9b000-7f11b109a000 ---p 0000d000 08:05 1978528 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_iostreams-gcc41-mt-p-1_38.so.1.38.0
7f11b109a000-7f11b109b000 rw-p 0000c000 08:05 1978528 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_iostreams-gcc41-mt-p-1_38.so.1.38.0
7f11b109b000-7f11b1153000 r-xp 00000000 08:05 1978529 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_regex-gcc41-mt-p-1_38.so.1.38.0
7f11b1153000-7f11b1252000 ---p 000b8000 08:05 1978529 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_regex-gcc41-mt-p-1_38.so.1.38.0
7f11b1252000-7f11b1257000 rw-p 000b7000 08:05 1978529 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libboost_regex-gcc41-mt-p-1_38.so.1.38.0
7f11b1257000-7f11b1260000 r-xp 00000000 08:05 1978503 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libMiniZip.so
7f11b1260000-7f11b145f000 ---p 00009000 08:05 1978503 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libMiniZip.so
7f11b145f000-7f11b1460000 rw-p 00008000 08:05 1978503 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libMiniZip.so
7f11b1460000-7f11b1476000 r-xp 00000000 08:05 1978525 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libZlib.so
7f11b1476000-7f11b1675000 ---p 00016000 08:05 1978525 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libZlib.so
7f11b1675000-7f11b1676000 rw-p 00015000 08:05 1978525 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libZlib.so
7f11b1676000-7f11b1680000 r-xp 00000000 08:05 1978518 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libThread.so
7f11b1680000-7f11b187f000 ---p 0000a000 08:05 1978518 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libThread.so
7f11b187f000-7f11b1880000 rw-p 00009000 08:05 1978518 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libThread.so
7f11b1880000-7f11b1883000 rw-p 00000000 00:00 0
7f11b1883000-7f11b188b000 r-xp 00000000 08:05 1978507 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libPort_Std.so
7f11b188b000-7f11b1a8a000 ---p 00008000 08:05 1978507 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libPort_Std.so
7f11b1a8a000-7f11b1a8b000 rw-p 00007000 08:05 1978507 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libPort_Std.so
7f11b1a8b000-7f11b1c8d000 rwxp 00000000 08:05 1978502 /opt/Xilinx/14.4/ISE_DS/ISE/lib/lin64/libisl_iostreams.soERROR:Simulator:772 - Signal SIGABRT received
Printing stacktrace...
[0] /lib/x86_64-linux-gnu/libc.so.6(+0x6d52b) [0x7f11af7bb52b]
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x76d76) [0x7f11af7c4d76]
[2] /lib/x86_64-linux-gnu/libc.so.6(+0x7a658) [0x7f11af7c8658]
[3] /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x70) [0x7f11af7c9b90]
[4] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libstlport.so.5.1(operator new(unsigned long)+0x1d) [0x7f11b2b7909d]
[5] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libPortability.so(Port_MsgManData::createObject(char const*, char const*, int, char const*)+0x33) [0x7f11b286a043]
[6] /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse() [0x5fe2ba]
[7] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030) [0x7f11b0180030]
[8] /lib/x86_64-linux-gnu/libc.so.6(+0x1277fc) [0x7f11af8757fc]
[9] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::Array::Remove(unsigned int, unsigned int)+0x3a) [0x7f11b3748906]
[10] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlSubprogramId::ElaboratePragmaProcedure(Verific::Array const*, Verific::VhdlDataFlow*)+0x145f) [0x7f11b3a2e295]
[11] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlSubprogramId::ElaborateSubprogram(Verific::Array*, Verific::VhdlConstraint*, Verific::VhdlDataFlow*, Verific::VhdlTreeNode*, Verific::VhdlIdDef*)+0xf3) [0x7f11b3a2e8b1]
[12] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlIndexedName::Evaluate(Verific::VhdlConstraint*, Verific::VhdlDataFlow*, unsigned int)+0x12b) [0x7f11b3a4cc81]
[13] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlProcedureCallStatement::Elaborate(Verific::VhdlDataFlow*, Verific::VhdlBlockConfiguration*)+0x3e) [0x7f11b3a85c7a]
[14] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlWhileScheme::Elaborate(Verific::VhdlIdDef*, Verific::Array*, Verific::Array*, Verific::VhdlBlockConfiguration*, Verific::VhdlDataFlow*)+0x2b3) [0x7f11b3a38867]
[15] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlLoopStatement::Elaborate(Verific::VhdlDataFlow*, Verific::VhdlBlockConfiguration*)+0xfe) [0x7f11b3a85da8]
[16] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlIfStatement::ElaborateCore(Verific::VhdlDataFlow*)+0x24f) [0x7f11b3a88731]
[17] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlIfStatement::Elaborate(Verific::VhdlDataFlow*, Verific::VhdlBlockConfiguration*)+0x52) [0x7f11b3a88e8a]
[18] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlWhileScheme::Elaborate(Verific::VhdlIdDef*, Verific::Array*, Verific::Array*, Verific::VhdlBlockConfiguration*, Verific::VhdlDataFlow*)+0x2b3) [0x7f11b3a38867]
[19] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlLoopStatement::Elaborate(Verific::VhdlDataFlow*, Verific::VhdlBlockConfiguration*)+0xfe) [0x7f11b3a85da8]
[20] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlSubprogramBody::ElaborateSubprogram(Verific::Array const*, Verific::VhdlConstraint*, Verific::VhdlDataFlow*, Verific::VhdlTreeNode*, unsigned int, Verific::VhdlIdDef*)+0x1217) [0x7f11b3a10cdf]
[21] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlSubprogramId::ElaborateSubprogram(Verific::Array*, Verific::VhdlConstraint*, Verific::VhdlDataFlow*, Verific::VhdlTreeNode*, Verific::VhdlIdDef*)+0x1aa) [0x7f11b3a2e968]
[22] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlIndexedName::Evaluate(Verific::VhdlConstraint*, Verific::VhdlDataFlow*, unsigned int)+0x12b) [0x7f11b3a4cc81]
[23] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlConstantDecl::Elaborate(Verific::VhdlDataFlow*)+0x8b) [0x7f11b3a0d7f1]
[24] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlArchitectureBody::StaticElaborate(Verific::VhdlBlockConfiguration*)+0x9e) [0x7f11b3ac9c54]
[25] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlEntityDecl::StaticElaborateInternal(char const*, Verific::Array*, Verific::Array*, Verific::VhdlBlockConfiguration*, Verific::VhdlIdDef*)+0x3ff) [0x7f11b3ac91d1]
[26] /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libVrfc_Verific.so(Verific::VhdlEntityDecl::StaticElaborate(char const*, Verific::Array*, Verific::Array*, Verific::VhdlBlockConfiguration*, Verific::VhdlIdDef*)+0x157) [0x7f11b3ac7f35]
[27] /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse(ISIMC::Fuse::elaborateDesign()+0x27a) [0x4550aa]
[28] /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse(ISIMC::Fuse::run()+0x117) [0x46aaf7]
[29] /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse(ISIMC::Fuse::main(int, char**)+0x59) [0x46bcb9]
[30] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f11af76cead]
[31] /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/unwrapped/fuse(__gxx_personality_v0+0x209) [0x451c49]
PGM is an ASCII-based format, which is as well because ISE Simulator has issues accessing binary files. (It can be done, but you have to jump through a few hoops, including a 9-byte header that Xilinx actually refuse to document)
The most likely cause is that you are attempting to return a fixed size 640x640x4 byte array on the stack, regardless of the actual image size. Whoever wrote that package needs their head examined.
But before going further along this line of reasoning, it is worth checking that a much smaller array on the stack will work. Find a small PGMfile (say, 16*16) and edit the package for a "max" slightly larger than the file (20*20 or 32*32 should be safe).
Assuming that works, report back and we can work out a more appropriate solution : either a procedure with an OUT parameter (caller allocates it) or a function returning an access type (pointer) to the actual storage.
Alternatively : try GHDL as an alternative simulator. It has runtime options to control the stack size, which may bypass the problem.
EDIT following some experimentation:
(1) The "memory corruption" appears to arise on lines containing white space after the data. Deleting that in a text editor removes that issue (rewriting the line parser to eliminate that problem is probably a better answer...)
(2) After fixing that, the elaboration stage appears to hang.
A few asserts after the line pgm.pixel(pi,pj) := number; reveal that it IS actually running; crawling or slithering might be a better term. I haven't actually summed up the patience to let it run beyond line 100 so I can't say if the result is successful.
pgm.pixel(pi,pj) := number;
assert pi < 10 report "Pixel " & natural'image(pi) & " : " & natural'image(pj) severity note;
(etc)
EDIT following further digging:
Apparently ISIM treats elaboration differently from runtime computation; assuming that little or no actual work is done there, and its elaboration is neither to the same quality nor performance as the executable operating at simulation time.
So replacing the architecture with:
architecture behavioral of test_raw_tb is
--constant infile : pgm_record_type := read_pgm_file(ifile);
begin -- architecture
process
variable infile : pgm_record_type;
begin
infile := read_pgm_file(ifile);
wait;
end process;
end behavioral;
as one way of forcing the file parsing to be deferred until runtime; compilation succeeds, and simulation proceeds at a satisfactory speed until:
ERROR: Index 640 out of bound 0 to 639.
ERROR: In process test_raw_tb.vhd:17
(this error does not occur with the whitespace fixed file, so there still seems to be a parser issue to address)
I have created a asp.net application with framework 4.0.
It has a sort of interview screen with so many questions on it with the paging.
It may have 1000 pages with 10 questions in each page.
when users are using this application screen randomly gets frozen and asks for window credentials.
We also keep getting error for the same application in error log as below:
A process serving application pool 'appicationpoolname' suffered a
fatal communication error with the Windows Process Activation Service.
The process id was '4768'. The data field contains the error number.
Not sure if both above error are related or not.
I have created a rule in debugdiag tool for application pool crash and that has generated a dump file. The full call stack for the dump file is as below
Function Arg 1 Arg 2 Arg 3 Arg 4 Source
KERNELBASE!RaiseException+58 04242420 00000000 00000003 010ce504
clr!Debugger::SendRawEvent+9b 010ce530 0000002f 0000015c 000012a0
clr!Debugger::RaiseStartupNotification+48 6fa92811 00000001 01000000 00000000
clr!Debugger::Startup+73 6fa92bf9 00000001 01000000 00000000
clr!DoAdditionalPEChecks+e5 6fa92ac5 00000001 00000000 00000000
clr!EEStartupHelper+5f4 00000000 6fa92a9d 00000001 00000000
clr!EEStartup+52 00000000 6fa92a41 00000001 00000000
clr!EnsureEEStarted+c4 00000000 6fa92f9d 014bb2c0 00000000
clr!ClrCreateManagedInstance+41 708d4bb8 708d4ca8 010ceeb4 00000000
webengine4!LegacyActivationShim::ClrCreateManagedInstance+61 708d4bb8 708d4ca8 010ceeb4 00c6e268
webengine4!GetIsapiProcessHost+48 00c6e268 01c44e8c 6d8e0000 01c44e68
webengine!GetIsapiProcessHost+d0 00c6e268 01c44e8c 00b907d8 00000000
wbhst_pm+2e2a 01c4fed8 01c44e68 00000000 010cf56c
wbhst_pm+335f 00b907d8 01c4fed8 01c4fdf0 010cf5e4
wbhst_pm!GetProtocolManager+35 00b907d8 01c4fed8 00000000 00b90898
w3wphost!AppHostInitialize+235e 7534415b 00000000 00000000 00000000
w3wphost!AppHostInitialize+2698 010cf69c 708e199c 010cf618 00000001
w3wphost!IPM_MESSAGE_PIPE::operator=+1c03 010cf69c 708e199c 00000001 708f1274
iiscore!W3_SERVER::GetProtocolManagerCustomInterface+36 010cf69c 708e199c 00000001 708f1274
webengine4!InitClrHost+186 708f1274 00000000 014c8004 00000400
webengine4!CMgdEngGlobalModule::OnGlobalApplicationResolveModules+31 01c4efac 01c40330 010cf77c 7210a67a
iiscore!VIRTUAL_MODULE::GlobalDoWork+152 00000400 01c4efac 01c4efa8 01c4efa8
iiscore!W3_SERVER::GlobalNotify+98 00000400 01c4efac 00000000 72122f3a
iiscore!W3_APPLICATION::ResolveModules+22 014cc280 00000000 014cc284 00000001
iiscore!W3_APPLICATION::SetupNotificationContext+95 00000000 00000001 014cc284 014cc2e0
iiscore!W3_CONTEXT::SetupStateMachinePhase2+2ab 014cc280 014cc284 00000000 72103358
iiscore!W3_CONTEXT::SetupStateMachine+241 014cc284 014cc280 75341400 010cf894
iiscore!W3_MAIN_CONTEXT::StartNotificationLoop+3f 014cc284 00000000 00c712a8 014cb828
iiscore!W3_MAIN_CONTEXT::OnNewRequest+47 014cb828 014cb828 72a914e6 753413f0
w3dt!UL_NATIVE_REQUEST::DoStateProcess+26 753413f0 010cf8c0 72a9154c 00000444
w3dt!UL_NATIVE_REQUEST::DoWork+60 00000444 00000000 014cb82c 010cf8f8
w3dt!OverlappedCompletionRoutine+1a 00000000 00000444 014cb82c 00c712b0
w3tp!THREAD_POOL_DATA::ThreadPoolThread+89 00000000 00be7fd8 72cf0000 010cf924
w3tp!THREAD_POOL_DATA::ThreadPoolThread+24 00c712a8 00000000 00000000 00be7fd8
w3tp!THREAD_MANAGER::ThreadManagerThread+39 00be7fd8 010cf970 770f9ed2 00be7fd8
kernel32!BaseThreadInitThunk+12 00be7fd8 590a45de 00000000 00000000
ntdll!__RtlUserThreadStart+70 72cf1e5c 00be7fd8 ffffffff 771872ff
ntdll!_RtlUserThreadStart+1b 72cf1e5c 00be7fd8 00000000 00000000
Exception Information
In W3WP__~1.DMP the assembly instruction at KERNELBASE!RaiseException+58 in C:\Windows\SysWOW64\KERNELBASE.dll from Microsoft Corporation has caused an unknown exception (0x04242420) on thread 5
I am not sure how to use this to fix the issue. I tried using Winddbg with .loadby sos mscorwks
command but it says invalid module mscorwks
Any help would be appriciated.
Thanks,
MMC
Is this a first chance exception dump or a second chance exception dump ? When you created the rule in Debug Diagnostic tool, did you change something in the Unconfigured first chance exceptions section ?
Based on the stack it seems this is a first chance exception dump. Make sure that you change the Action time for un-configured first chance exceptions to NONE and then let the tool generate a second chance exception dump and that would be worth to look at.
If it generates one, analyze it using debugdiag and paste the stack and we can see why it is crashing
I am learning socket programming under Linux,so I make a sample program to list all the network interface,here is the code
/* print the name of interface */
#include <sys/socket.h>
#include <net/if.h>
#include <stdio.h>
int
main(void)
{
struct if_nameindex *pif;
pif = if_nameindex();
while (pif->if_index) {
printf("name: %s \t index: %d\n", pif->if_name, pif->if_index);
pif++;
}
if_freenameindex(pif);
printf("after the first if_freenameindex call\n");
return 0;
}
run it and it returns
name: lo index: 1
name: eth0 index: 2
name: eth1 index: 3
name: eth2 index: 4
*** glibc detected *** ./if: double free or corruption (out): 0x0983b420 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7edb624]
/lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7edd826]
/lib/i686/cmov/libc.so.6(if_freenameindex+0x40)[0xb7f6f9e0]
./if[0x80484b6]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7e83455]
./if[0x80483d1]
======= Memory map: ========
08048000-08049000 r-xp 00000000 03:01 51169 /home/jcyang/src/net/gnu/if
08049000-0804a000 rw-p 00000000 03:01 51169 /home/jcyang/src/net/gnu/if
0983b000-0985c000 rw-p 0983b000 00:00 0 [heap]
b7d00000-b7d21000 rw-p b7d00000 00:00 0
b7d21000-b7e00000 ---p b7d21000 00:00 0
b7e54000-b7e60000 r-xp 00000000 03:01 73587 /lib/libgcc_s.so.1
b7e60000-b7e61000 rw-p 0000b000 03:01 73587 /lib/libgcc_s.so.1
b7e6c000-b7e6d000 rw-p b7e6c000 00:00 0
b7e6d000-b7fc2000 r-xp 00000000 03:01 82774 /lib/i686/cmov/libc-2.7.so
b7fc2000-b7fc3000 r--p 00155000 03:01 82774 /lib/i686/cmov/libc-2.7.so
b7fc3000-b7fc5000 rw-p 00156000 03:01 82774 /lib/i686/cmov/libc-2.7.so
b7fc5000-b7fc9000 rw-p b7fc5000 00:00 0
b7fd3000-b7fd5000 rw-p b7fd3000 00:00 0
b7fd5000-b7fd6000 r-xp b7fd5000 00:00 0 [vdso]
b7fd6000-b7ff0000 r-xp 00000000 03:01 73586 /lib/ld-2.7.so
b7ff0000-b7ff2000 rw-p 0001a000 03:01 73586 /lib/ld-2.7.so
bffdc000-bfff1000 rw-p bffeb000 00:00 0 [stack]
Aborted
Acoording to the GNU C Library Reference Manaul,we should use if_freenameindex to free the earily returned if_nameindex.So whats wrong?
thanks.
You should call if_freenameindex() on first pif, not the final one. for example:
struct if_nameindex *pif;
struct if_nameindex *head;
head = pif = if_nameindex();
while (pif->if_index) {
printf("name: %s \t index: %d\n", pif->if_name, pif->if_index);
pif++;
}
if_freenameindex(head);
....