On Sun, Dec 17, 2017 at 4:31 PM, John Reiser wrote:
> Then there's the subtle point that filing bugzilla encourages
> the exhibit of a reproducible test case: the actual command line,
> the actual .rpms for the program and libraries,
> the actual environment variables, attaching [or linking]
> to
On 12/17/2017 13:57 UTC, Tony Nelson wrote:
On 17-12-17 14:33:43, John Reiser wrote:
...
At this point I suggest to file a bugzilla report against the compiler
for not keeping %rsp 16-byte aligned. Include the traceback and
the register info from the gdb session at SIGSEGV, and the identities
On 17-12-17 14:33:43, John Reiser wrote:
...
At this point I suggest to file a bugzilla report against the compiler
for not keeping %rsp 16-byte aligned. Include the traceback and
the register info from the gdb session at SIGSEGV, and the identities
(.so name, build-id, .rpm name) of the shared
On Sun, Dec 17, 2017 at 1:33 PM, John Reiser wrote:
>
> Anyway, the focus now shifts to the backtrace from
> https://pastebin.com/LCDQpB5d :
> #0 __GI__dl_catch_error
> #1 0x763b76a5 in _dlerror_run at dlerror.c:163
> #2 0x763b701f in __dlclose at dlclose.c:46
> #3 0x74
At this point ...
You could also plant a breakpoint at the <+0> of each routine
named in the traceback, and print %rsp. It should be (8 mod 16)
because the dynamically-preceding 'call' should have pushed 8 bytes
when the %rsp was 16-byte aligned.
(gdb) b * # use a numerical address, NOT a sym
Dump of assembler code for function __GI__dl_catch_error:
0x76136100 <+0>:push %rbx
0x76136101 <+1>:sub $0x140,%rsp
0x76136108 <+8>:lea 0x4c(%rsp),%rax
0x7613610d <+13>:mov %rdi,0x10(%rsp)
0x76136112 <+18>:mov %rsi,0x8(%
Dump of assembler code for function __GI__dl_catch_error:
0x76136100 <+0>: push %rbx
0x76136101 <+1>: sub$0x140,%rsp
0x76136108 <+8>: lea0x4c(%rsp),%rax
0x7613610d <+13>: mov%rdi,0x10(%rsp)
0x76136112 <+18>: mov%rsi,0x8(%rsp)
https://pastebin.com/r03HxDrX
rsp0x7fffd6e8 0x7fffd6e8 BAD: not 16-byte aligned
pc=> 0x7613616c <__GI__dl_catch_error+108>:movaps %xmm0,0x50(%rsp)
The problem is that the effective address 0x...738 is not 16-byte aligned,
and this generates SIGSEGV because
On Sun, Dec 17, 2017 at 8:04 AM, John Reiser wrote:
>
> SIGSEGV is a bad memory reference, but none of those URLs gives any info
> about the memory reference itself: the address, the size,
> Read/Write/Execute,
> the program counter value, the contents of the instruction stream.
> The pastebin inf
On 12/17/2017 12:58 UTC, Richard Shaw wrote:
Ok, so I built the latest version of hedgewars (0.9.23) and submitted an update
and quickly found out that when the game exits (hwengine, not the hedgewars
binary) it get's a segmentation fault.
http://hedgewars.org/node/6879?page=0
https://github
Hello, Richard.
I've happened to stumble across a very similar issue recently. I've been
working on an update to Colorful - which, like Hedgewars, is a game written in
Pascal and compiled with FPC - and the game gives me an Access Violation upon
exiting. This happens after all of "my" code has
Ok, so I built the latest version of hedgewars (0.9.23) and submitted an
update and quickly found out that when the game exits (hwengine, not the
hedgewars binary) it get's a segmentation fault.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-f9a419a9e9
I have posted to the hedgewars support
12 matches
Mail list logo
