I am using linux (ubuntu 9.26) version of ghostscript. When I try to convert the postscript file into pdf using the following:
$ gs -dNOPAUSE -dBATCH -sOutputFile=test.pdf -sDEVICE=pdfwrite -c . setpdfwrite -f d00040-001.ps
The output I get is the following:
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefined in .
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:970/1684(ro)(G)-- --dict:0/20(G)-- --dict:77/200(L)--
Current allocation mode is local
GPL Ghostscript 9.26: Unrecoverable error, exit code 1
```
Where can I look and how can I debug the above issue?
Leave out the "-c . setpdfwrite -f" from your command line.
Related
I am learning baremetal development on ARM, for which I chose to simulate Raspi3 on QEMU. Hence, its a virtual ARM Cortex A-53 imlementing ARMv8 architecture. I have compiled the following simple baremetal code :
.global _start
_start:
1: wfe
b 1b
I launch it using :
qemu-system-aarch64 -M raspi3 -kernel kernel8.img -display none -S -s
and the GDB is connected to it from the other terminal using :
gdb-multiarch ./kernel8.elf -ex 'target remote localhost:1234' -ex 'break *0x80000' -ex 'continue'
So far everything is good and I can notice the breakpoint in gdb.
Reading symbols from ./kernel8.elf...
Remote debugging using localhost:1234
0x0000000000000000 in ?? ()
Breakpoint 1 at 0x80000: file start.S, line 5.
Continuing.
Thread 1 hit Breakpoint 1, _start () at start.S:5
5 1: wfe
(gdb) info threads
Id Target Id Frame
* 1 Thread 1.1 (CPU#0 [running]) _start () at start.S:5
2 Thread 1.2 (CPU#1 [running]) 0x0000000000000300 in ?? ()
3 Thread 1.3 (CPU#2 [running]) 0x000000000000030c in ?? ()
4 Thread 1.4 (CPU#3 [running]) 0x000000000000030c in ?? ()
(gdb) list
1 .section ".text.boot"
2
3 .global _start
4 _start:
5 1: wfe
6 b 1b
(gdb)
As per my understanding, in case of ARM all the cores will execute the same code on reset, so ideally all the cores in my case must be running the same code. I just want to verify that by putting breakpoints and that is the problem. The break points for other cores are not hit. If I am not wrong, the threads in my case are nothing but the cores. I tried putting break but does not work :
(gdb) break *0x80000 thread 2
Note: breakpoint 1 (all threads) also set at pc 0x80000.
Breakpoint 2 at 0x80000: file start.S, line 5.
(gdb) thread 2
[Switching to thread 2 (Thread 1.2)]
#0 0x0000000000000300 in ?? ()
(gdb) info threads
Id Target Id Frame
1 Thread 1.1 (CPU#0 [running]) _start () at start.S:5
* 2 Thread 1.2 (CPU#1 [running]) 0x0000000000000300 in ?? ()
3 Thread 1.3 (CPU#2 [running]) 0x000000000000030c in ?? ()
4 Thread 1.4 (CPU#3 [running]) 0x000000000000030c in ?? ()
(gdb) s
Cannot find bounds of current function
(gdb) c
Continuing.
[Switching to Thread 1.1]
Thread 1 hit Breakpoint 1, _start () at start.S:5
5 1: wfe
(gdb)
I deleted the core 1 breakpoint, and then the core 2 hangs forever :
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000080000 start.S:5
breakpoint already hit 2 times
2 breakpoint keep y 0x0000000000080000 start.S:5 thread 2
stop only in thread 2
(gdb) delete br 1
(gdb) info break
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000080000 start.S:5 thread 2
stop only in thread 2
(gdb) thread 2
[Switching to thread 2 (Thread 1.2)]
#0 0x000000000000030c in ?? ()
(gdb) c
Continuing.
What can I do get a breakpoint on core 2? What am I doing wrong here?
EDIT
I tried set scheduler-locking on (assuming this is what I need) but this also seems not working for me.
(gdb) break *0x80000
Breakpoint 3 at 0x80000: file start.S, line 5.
(gdb) thread 2
[Switching to thread 2 (Thread 1.2)]
#0 0x000000000000030c in ?? ()
(gdb) set scheduler-locking on
(gdb) c
Continuing.
^C/build/gdb-OxeNvS/gdb-9.2/gdb/inline-frame.c:367: internal-error: void skip_inline_frames(thread_info*, bpstat): Assertion `find_inline_frame_state (thread) == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
This is a bug, please report it. For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.
/build/gdb-OxeNvS/gdb-9.2/gdb/inline-frame.c:367: internal-error: void skip_inline_frames(thread_info*, bpstat): Assertion `find_inline_frame_state (thread) == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n)
EDIT 2
Upon #Frank's advice, I built (latest) qemu 6.2.0 locally and used the gdb available in the arm toolchain.
naveen#workstation:~/.repos/src/arm64/baremetal/raspi3-tutorial/01_bareminimum$ /opt/qemu-6.2.0/build/qemu-system-aarch64 -version
QEMU emulator version 6.2.0
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
naveen#workstation:~/.repos/src/arm64/baremetal/raspi3-tutorial/01_bareminimum$ /opt/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gdb -version
GNU gdb (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.2.90.20210621-git
But I am still having the problem. My other cores 2,3 and 4 never hit the breakpoints. It seems they are not even running my code, as the address they are pointing to, does not look ok.
(gdb) info threads
Id Target Id Frame
* 1 Thread 1.1 (CPU#0 [running]) _start () at start.S:5
2 Thread 1.2 (CPU#1 [running]) 0x000000000000030c in ?? ()
3 Thread 1.3 (CPU#2 [running]) 0x000000000000030c in ?? ()
4 Thread 1.4 (CPU#3 [running]) 0x000000000000030c in ?? ()
EDIT 3
The problem seems with my Makefile, as when I used the command to build, as suggested by Frank, it worked for me. Can someone please look as what's wrong with this Makefile :
CC = /opt/gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf/bin/aarch64-none-elf
CFLAGS = -Wall -O2 -ffreestanding -nostdinc -nostartfiles -nostdlib -g
all: clean kernel8.img
start.o: start.S
${CC}-gcc $(CFLAGS) -c start.S -o start.o
kernel8.img: start.o
${CC}-ld -g -nostdlib start.o -T link.ld -o kernel8.elf
${CC}-objcopy -O binary kernel8.elf kernel8.img
clean:
rm kernel8.elf kernel8.img *.o >/dev/null 2>/dev/null || true
EDIT 4
It turns out that when I use kernel8.elf with QEMU for booting, everything works as expected. But when I use kernel8.img which is a binary format, I get the issue. With bit of reading, I understand that ELF contains the "extra" information required to make the example work. But for clarification, how can I make the kernel8.img work?
You probably have an issue with the versions of gdb or qemu you are using, since I was not able to reproduce your problem with a version 10.1 of aarch64-elf-gdb and a version 6.2.0 of qemu-system-aarch64 compiled from scratch on an Ubuntu 20.04.3 LTS system:
wfe.s:
.global _start
_start:
1: wfe
b 1b
Building wfe.elf:
/opt/arm/10/gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf/bin/aarch64-none-elf-gcc -g -ffreestanding -nostdlib -nostartfiles -Wl,-Ttext=0x80000 -o wfe.elf wfe.s
Looking at generated code:
/opt/arm/10/gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf/bin/aarch64-none-elf-objdump -d wfe.elf
wfe.elf: file format elf64-littleaarch64
Disassembly of section .text:
0000000000080000 <_stack>:
80000: d503205f wfe
80004: 17ffffff b 80000 <_stack>
Starting qemu in a shell session:
/opt/qemu-6.2.0/bin/qemu-system-aarch64 -M raspi3b -kernel wfe.elf -display none -S -s
Starting gdb in another:
/opt/gdb/gdb-10.1-aarch64-elf-x86_64-linux-gnu/bin/aarch64-elf-gdb wfe.elf -ex 'target remote localhost:1234' -ex 'break *0x80000' -ex 'continue'
gdb session:
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=aarch64-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using localhost:1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000000000080000 in ?? ()
Breakpoint 1 at 0x80000
Continuing.
[Switching to Thread 1.4]
Thread 4 hit Breakpoint 1, 0x0000000000080000 in ?? ()
(gdb) break *0x80000 thread 2
Note: breakpoint 1 (all threads) also set at pc 0x80000.
Breakpoint 2 at 0x80000
(gdb) info threads
Id Target Id Frame
1 Thread 1.1 (CPU#0 [running]) 0x0000000000080000 in ?? ()
2 Thread 1.2 (CPU#1 [running]) 0x0000000000080000 in ?? ()
3 Thread 1.3 (CPU#2 [running]) 0x0000000000080000 in ?? ()
* 4 Thread 1.4 (CPU#3 [running]) 0x0000000000080000 in ?? ()
(gdb) c
Continuing.
[Switching to Thread 1.2]
Thread 2 hit Breakpoint 1, 0x0000000000080000 in ?? ()
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000080000
breakpoint already hit 2 times
2 breakpoint keep y 0x0000000000080000 thread 2
stop only in thread 2
breakpoint already hit 1 time
(gdb) del 1
(gdb) info b
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000080000 thread 2
stop only in thread 2
breakpoint already hit 1 time
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, 0x0000000000080000 in ?? ()
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, 0x0000000000080000 in ?? ()
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, 0x0000000000080000 in ?? ()
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, 0x0000000000080000 in ?? ()
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, 0x0000000000080000 in ?? ()
(gdb)
The anwers to your two questions are therefore:
What can I do get a breakpoint on core 2?
Exactly what you are doing.
What am I doing wrong here?
Nothing, but may be using old/buggy versions of gdb and/or qemu - my guess would be that gdb is the culprit is your case, but I may be wrong.
You can easily verify by testing again using the version of gdb provided in the gcc toolchain available from Arm, AArch64 ELF bare-metal target (aarch64-none-elf) - I tried, and it worked fine as well:
/opt/arm/10/gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf/bin/aarch64-none-elf-gdb wfe.elf -ex 'target remote localhost:1234' -ex 'break *0x80000' -ex 'continue'
GNU gdb (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.2.90.20210621-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=aarch64-none-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.linaro.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from wfe.elf...
Remote debugging using localhost:1234
_start () at wfe.s:3
3 1: wfe
Breakpoint 1 at 0x80000: file wfe.s, line 3.
Continuing.
Thread 1 hit Breakpoint 1, _start () at wfe.s:3
3 1: wfe
(gdb) break *0x80000 thread 2
Note: breakpoint 1 (all threads) also set at pc 0x80000.
Breakpoint 2 at 0x80000: file wfe.s, line 3.
(gdb) info threads
Id Target Id Frame
* 1 Thread 1.1 (CPU#0 [running]) _start () at wfe.s:3
2 Thread 1.2 (CPU#1 [running]) _start () at wfe.s:3
3 Thread 1.3 (CPU#2 [running]) _start () at wfe.s:3
4 Thread 1.4 (CPU#3 [running]) _start () at wfe.s:3
(gdb) c
Continuing.
[Switching to Thread 1.2]
Thread 2 hit Breakpoint 1, _start () at wfe.s:3
3 1: wfe
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000080000 wfe.s:3
breakpoint already hit 2 times
2 breakpoint keep y 0x0000000000080000 wfe.s:3 thread 2
stop only in thread 2
breakpoint already hit 1 time
(gdb) del 1
(gdb) info b
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000080000 wfe.s:3 thread 2
stop only in thread 2
breakpoint already hit 1 time
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, _start () at wfe.s:3
3 1: wfe
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, _start () at wfe.s:3
3 1: wfe
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, _start () at wfe.s:3
3 1: wfe
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, _start () at wfe.s:3
3 1: wfe
(gdb) c
Continuing.
Thread 2 hit Breakpoint 2, _start () at wfe.s:3
3 1: wfe
(gdb)
Please note that explaining how to build the latest versions of gdb and qemu is out of the scope of the current answer.
I have a super simple script to confirm this behavior:
leak.sh
#! /bin/bash
echo "Am I leaking?"
Execute under valgrind...
$ valgrind ./leak.sh
==1365336== Memcheck, a memory error detector
==1365336== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1365336== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1365336== Command: ./leak.sh
==1365336==
Am I leaking?
==1365336==
==1365336== HEAP SUMMARY:
==1365336== in use at exit: 50,076 bytes in 766 blocks
==1365336== total heap usage: 858 allocs, 92 frees, 59,487 bytes allocated
==1365336==
==1365336== LEAK SUMMARY:
==1365336== definitely lost: 12 bytes in 1 blocks
==1365336== indirectly lost: 0 bytes in 0 blocks
==1365336== possibly lost: 0 bytes in 0 blocks
==1365336== still reachable: 50,064 bytes in 765 blocks
==1365336== suppressed: 0 bytes in 0 blocks
==1365336== Rerun with --leak-check=full to see details of leaked memory
==1365336==
==1365336== For lists of detected and suppressed errors, rerun with: -s
==1365336== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
If you change the script to use the dash, the default shell (sh) for Pop!_OS (and I assume all Debian distros), then it will run without leaking.
no_leak.sh
#! /bin/dash
echo "Am I leaking?"
$ valgrind ./no_leak.sh
==1365800== Memcheck, a memory error detector
==1365800== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1365800== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1365800== Command: ./no_leak.sh
==1365800==
Am I leaking?
==1365800==
==1365800== HEAP SUMMARY:
==1365800== in use at exit: 10,666 bytes in 77 blocks
==1365800== total heap usage: 80 allocs, 3 frees, 14,809 bytes allocated
==1365800==
==1365800== LEAK SUMMARY:
==1365800== definitely lost: 0 bytes in 0 blocks
==1365800== indirectly lost: 0 bytes in 0 blocks
==1365800== possibly lost: 0 bytes in 0 blocks
==1365800== still reachable: 10,666 bytes in 77 blocks
==1365800== suppressed: 0 bytes in 0 blocks
==1365800== Rerun with --leak-check=full to see details of leaked memory
==1365800==
==1365800== For lists of detected and suppressed errors, rerun with: -s
==1365800== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Where can I report this observation, or find out if it has already been addressed?
bash Version
$ bash --version
GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
As mentioned by #oguz_ismail in the comments, bug-bash#gnu.org is the appropriate place to report the bug.
However, a certain format for the email is required/requested, when you need to report a bug.
All bug reports should include:
The version number of Bash.
The hardware and operating system.
The compiler used to compile Bash.
A description of the bug behaviour.
A short script or ‘recipe’ which exercises the bug and may be used to reproduce it.
You can find ALL the details at:
https://www.gnu.org/software/bash/manual/html_node/Reporting-Bugs.html
Finally, there is a helper script built into bash itself. Call bashbug from the command line, and it will populate most of the requirements, leaving you to fill out the description and the steps required to reproduce the bug.
$ bashbug
GNU nano 5.2 /tmp/bbug.1414628/bbug1
From: zak
To: bug-bash#gnu.org
Subject: [50 character or so descriptive subject here (for reference)]
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-SmNvvg/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-secu>
uname output: Linux pop-os 5.11.0-7614-generic #15~1618626693~20.10~ecb25cd-Ubuntu SMP Thu Apr 22 16:00:45 UTC x86_64 x86_64 x86_64 GNU/Linux
...
Once you have filled in the template, you will be prompted if you would like to send the email. It's okay if you don't have an email client connected, it will store the completed form at ~/dead.bashbug and you can copy paste it into your email client.
1.This is my mips assembly code
.data
out_string: .ascii "hello \n"
.text
.global main
main:
li $v0, 4
la $a0, out_string
syscall
li $v0, 10
syscall
2.Then I as the code
mipsel-linux-gun-as --march=mips2 word.S -o word.o
3.I use the gcc link the code
mipsel-linux-gun-gcc -L /usr/mipsel-linux-gun word.o -o word
4.I use the qemu simulation the mips enviroment to execute the bin . The I get some error !!!
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
Can you help me to compiler the mips code!
Thanks!
I cannot convert pdf to ps or ps to pdf. an example is given below. Please someone help me.
GS>pdf2ps f.pdf
Error: /undefined in pdf2ps
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- %loop_continue --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:1199/1684(ro)(G)-- --dict:0/20(G)-- --dict:78/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 7
pdf2ps is a shell script, not a PostScript program. You appear to have started the interpreter and reached the interactive prompt, which probably means you started Ghostscript without any arguments on the command line.
Either:
Use the pdf2ps script from the shell, it will launch Ghostscript with default arguments to create a PostScript file from the specified argument
Use Ghostscript with appropriate command line arguments (eg -sDEVICE=ps2write) to do the conversion yourself.
If you choose the latter route you will have to understand at least the basics of the Ghostscript command line options, but it will give you better control.
I get this error message from a Ghostscript call:
Error: /syntaxerror in -file-
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
--nostringval-- --nostringval-- false 1 %stopped_push 1926 1 3 %oparray_pop 1925 1 3 %oparray_
pop 1909 1 3 %oparray_pop 1803 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostr
ingval-- --nostringval-- --nostringval-- 2 %stopped_push
Dictionary stack:
--dict:1169/1684(ro)(G)-- --dict:0/20(G)-- --dict:77/200(L)--
Current allocation mode is local
Current file position is 215
GPL Ghostscript 9.05: Unrecoverable error, exit code 1
Does it mean that there is problem in the input Postscript file or does it mean something is wrong with my call or the installation?
The call was:
ps2pdf book.ps book.pdf
The input file book.ps exists in the current directory.
Is there a list of Ghostscript error messages and what they mean somewhere? (Google was not my friend in this case.)
This is not a Ghostscript error message, its a PostScript error message. The PostScript error messages are defined in the PostScript Language Reference Manual. Syntaxerror means pretty much what it says, the PostScript program contained a syntax error.
Things you can try:
Execute Ghostscript on the PostScript file to render the page, does it work ? (You don't say what OS you are suing but something like gs book.ps ought to work)
Try using Ghostscript directly instead of the ps2pdf script which merely wraps it. Again something like gs -sDEVICE=pdfwrite -o book.pdf book.ps
One of these may help by either working or giving more explicit errors.