Determine a thread's stack size and location - linux

how can I determine the base of a thread's stack and its size under Linux? Is there an available C/C++ API or a way to find out in gdb?
thanks

Here's a different method of doing this, involving reading /proc/self/maps. Unlike some of the other methods, it doesn't require special instrumentation at the start of your program and gives you an exact position for the end of the stack.
If you try cat /proc/self/maps, you get something like this:
00400000-0040c000 r-xp 00000000 08:01 6039736 /usr/bin/cat
0060b000-0060c000 r--p 0000b000 08:01 6039736 /usr/bin/cat
0060c000-0060d000 rw-p 0000c000 08:01 6039736 /usr/bin/cat
00908000-00929000 rw-p 00000000 00:00 0 [heap]
7fcdb1c68000-7fcdb1e01000 r-xp 00000000 08:01 6032628 /usr/lib/libc-2.21.so
7fcdb1e01000-7fcdb2000000 ---p 00199000 08:01 6032628 /usr/lib/libc-2.21.so
7fcdb2000000-7fcdb2004000 r--p 00198000 08:01 6032628 /usr/lib/libc-2.21.so
7fcdb2004000-7fcdb2006000 rw-p 0019c000 08:01 6032628 /usr/lib/libc-2.21.so
7fcdb2006000-7fcdb200a000 rw-p 00000000 00:00 0
7fcdb200a000-7fcdb202c000 r-xp 00000000 08:01 6032717 /usr/lib/ld-2.21.so
7fcdb21f5000-7fcdb21f8000 rw-p 00000000 00:00 0
7fcdb2209000-7fcdb222b000 rw-p 00000000 00:00 0
7fcdb222b000-7fcdb222c000 r--p 00021000 08:01 6032717 /usr/lib/ld-2.21.so
7fcdb222c000-7fcdb222d000 rw-p 00022000 08:01 6032717 /usr/lib/ld-2.21.so
7fcdb222d000-7fcdb222e000 rw-p 00000000 00:00 0
7ffe78c41000-7ffe78c62000 rw-p 00000000 00:00 0 [stack]
7ffe78dba000-7ffe78dbc000 r--p 00000000 00:00 0 [vvar]
7ffe78dbc000-7ffe78dbe000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
As you can see, there is a [stack] entry. This is probably what you're looking for.
An example program to parse this line out:
#include <stdio.h>
#include <unistd.h>
#include <string.h>
int main(int argc, char *argv[]) {
FILE *file = fopen("/proc/self/maps", "r");
char line[1024];
void *result = NULL;
while (!feof(file)) {
if (fgets(line, sizeof(line) / sizeof(char), file) == NULL) {
break;
}
unsigned long start, end, offset;
unsigned int devma, devmi, ino;
char perms[6];
char path[128];
if (sscanf(line, "%lx-%lx %5s %lx %d:%d %d %127s", &start, &end, &perms, &offset, &devma, &devmi, &ino, &path) != 8) {
continue; // could not parse. fail gracefully and try again on the next line.
}
if (strcmp(path, "[stack]") == 0) { // use [stack:TID] for a thread besides the main thread
printf("Stack found from %lx to %lx\n", start, end);
break;
}
}
fclose(file);
return 0;
}
This will print something like:
Stack found from 7fff91834000 to 7fff91855000
This is probably fairly close to what you're looking for.

If you're okay with not getting the exact top of the stack (which might be enough for some applications), traversing the frame pointers could work:
// main.c
#include <stdint.h>
// -fno-omit-frame-pointer might be required - otherwise you might get a crash
// might not be exactly at the top; but probably very close
void *stack_top() {
void **top;
asm("movq %%rbp, %0" : "=r" (top)); // set top to %rbp - replace with %ebp for 32-bit x86
// if top is higher in memory than the variable, then still part of the stack.
while ((uintptr_t) *top > (uintptr_t) &top) {
top = *top;
}
return top;
}
This works because the %rbp register (or %ebp register on 32-bit) is used to store the pointer to the base of the parent stack frame (where the saved %rbp or %ebp value is) - so we can iteratively traverse this linked list until we reach an invalid address.
Note that stack_top might fail in some cases relating to the &top comparison - my system terminated the linked list with a pointer to a location in the program loading code, so this was the best way that I found to detect this - but you'll want to test this thoroughly. (If anyone has a better way to detect the end of the chain, please add a comment.)
Example test program:
#include <stdio.h>
#include <pthread.h>
void *test_another_layer(int x) {
return stack_top();
}
void *subthread(void *ptr) {
void *st1 = stack_top();
void *st2 = test_another_layer(0);
void *st3 = &ptr;
printf("stack tops 2: %x %x %x\n", st1, st2, st3);
return NULL;
}
int main(int argc, char *argv[]) {
void *st1 = stack_top();
void *st2 = test_another_layer(0);
void *st3 = &argc;
printf("stack tops: %x %x %x\n", st1, st2, st3);
pthread_t ot;
if (pthread_create(&ot, NULL, subthread, NULL) != 0) {
perror("cannot create");
return 1;
}
if (pthread_join(ot, NULL) != 0) {
perror("cannot join");
return 2;
}
return 0;
}

Related

Why is my Rust executable mapped to such high addresses (near the stack) instead of 0x400000?

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

Why I can see the several same segments in the /proc/pid/maps output?

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.

Process virtual memory

Can process have a few virtual pages pointing to the same physical address in his same address space ?
I would like that virt_page1---> physical-X
and also that virt_page2 ---> physical-X
How can it be done ? Should it be done from the kernel space ?
what routines involves ?
if I would like to map shared library like this:
7ff2a90d8000-7ff2a928d000 r-xp 00000000 08:02 4980747 /lib/x86_64-linux-gnu/libc-2.15.so
7ff2a928d000-7ff2a948d000 ---p 001b5000 08:02 4980747 /lib/x86_64-linux-gnu/libc-2.15.so
7ff2a948d000-7ff2a9491000 r--p 001b5000 08:02 4980747 /lib/x86_64-linux-gnu/libc-2.15.so
7ff2a9491000-7ff2a9493000 rw-p 001b9000 08:02 4980747 /lib/x86_64-linux-gnu/libc-2.15.so
I see the mapping are private, does it mean that I can't map them again to other virtual address ? should I change the linker for that ?
Update:
While disabling ASLR I did the following:
int main(void)
{
int fd = open("/lib/x86_64-linux-gnu/libc-2.15.so", O_RDONLY);
void* f1 = mmap(0, 1748*1024, PROT_READ|PROT_EXEC, MAP_PRIVATE, fd, 0);
void *f2 = (void*)0x00007ffff7a1a000;
if (memcmp(f1, f2, 1748*1024) != 0) {
printf("DIFFER\n");
}
while(1);
return 0;
}
This is the .so mapping when there is no ASLR
00007ffff7a1a000 1748K r-x-- /lib/x86_64-linux-gnu/libc-2.15.so
So I mmap the regions of the above to other page & I got this:
00007ffff7e26000 1748K r-x-- /lib/x86_64-linux-gnu/libc-2.15.so
While I compare f1 & f2 I see the same data,
is it to say that I have now to virtual regions mapped to the same physical address which is the shared library portion of 1748K ?
Yes it's possible from the user space. The simplest method is to mmap the same file twice.
char templ[] = "XXXXXXXX";
int fd = mkstemp(templ);
ftruncate(fd, 1024);
void* f1 = mmap(0, 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
void* f2 = mmap(0, 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
strcpy (f1, "foo bar baz weep quup");
printf ("%p %s\n", f1, (char*)f1);
printf ("%p %s\n", f2, (char*)f2);

Xilinx fuse compilation of vhdl code fails on debian because of glibc memory corruption

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)

why normal call to if_freenameindex would double free if_nameindex?

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);
....

Resources