Hi René,
Actually we didn’t need to disable optimizations before. We did see this
problem with ooRexx 4.2.0 recently as well, and our colleague Marguerite
disable the optimizations. This appears to be a GCC bug.
I’ll check tomorrow if there is an open bug and see what we can do about it.
--
— Erico Mendonça
Dedicated Support Engineer
SUSE
Em 10/07/16 14:48, "René Jansen"
<rvjan...@xs4all.nl<mailto:rvjan...@xs4all.nl>> escreveu:
Indeed. I spent quite a few hours on this yesterday and today but I forgot to
report back.
@Rick, thanks for the suggestions; I am also of the opinion that it is an
optimizer bug. If I move the code around, it always chokes on the mov
0x8(%rbp),%rax instruction. Googling for that, I hit several articles that
discuss optimizing virtual function calls. There is very similar C++ code in
interpreter/memory/RexxMemory. Is that still used in combination with the
platform dependent versions around?
@Erico, did you hit any problem with building rexx.img with an optimizing GNU
C++ 6.X compiler on OpenSUSE? We cannot release non-optimized versions as they
are one third of the speed of the optimized code, that would regress the CPS -
which is very fine at the moment.
@Erich, I am happy that you confirm this; I first had some trouble to make sure
that older libraries from /usr/lib64 were not used and I have resorted to
putting std::cout calls to trace. We might have to revisit the @rpath settings
for Linux also.
I reverted all local work on this and have downgraded my C++ compiler for
OpenSUSE to 5.3.1, and have set the Jenkins build to Release; it builds without
a hitch.
I am sure we need to revisit this sometime in the future, let’s wait out a few
compiler releases and then investigate. If I can figure out how to set a
breakpoint in C++ in GDB I’ll send the generated code to the compiler
maintainers. Do I need the mangled names? Do I need the arguments? But first
there is the EK 2016 final - I think that is more distractive than the
Wimbledon final today.
best regards,
René.
On 10 jul. 2016, at 19:20, Erich Steinböck
<erich.steinbo...@gmail.com<mailto:erich.steinbo...@gmail.com>> wrote:
With this patch applied ..
--- interpreter/platform/unix/MemorySupport.cpp (revision 11101)
+++ interpreter/platform/unix/MemorySupport.cpp (working copy)
@@ -216,16 +216,9 @@
else /* uncommitted not enough need a new
pool */
{
MemorySegmentPool *newPool = new (minSize) MemorySegmentPool;
- if (newPool)
- { /* Did we get a new Pool? */
- next = newPool; /* Anchor it to end of chain */
- memoryObject.memoryPoolAdded(newPool); // tell the memory object
we'v added a new pool
- return newPool->newSegment(minSize);
- }
- else
- {
- return NULL;
- }
+ next = newPool; /* Anchor it to end of chain */
+ memoryObject.memoryPoolAdded(newPool); // tell the memory object we'v
added a new pool
+ return newPool->newSegment(minSize);
}
}
I compiled with gcc 6.1.1, ran into the same exception, and have this gdb
output:
erichst@erich-vm:~/oorexxbuild/611retail/bin$ gdb ./rexximage
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
...
This GDB was configured as "x86_64-linux-gnu".
...
Reading symbols from ./rexximage...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/erichst/oorexxbuild/611retail/bin/rexximage
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7b5d517 in MemorySegmentPool::newSegment(unsigned long) ()
from /home/erichst/oorexxbuild/611retail/bin/librexx.so.5.0.0
(gdb) thread apply all bt full
Thread 1 (Thread 0x7ffff7fe5740 (LWP 21587)):
#0 0x00007ffff7b5d517 in MemorySegmentPool::newSegment(unsigned long) ()
from /home/erichst/oorexxbuild/611retail/bin/librexx.so.5.0.0
No symbol table info available.
#1 0x00007ffff7b26af6 in MemoryObject::newSegment(unsigned long, unsigned
long) () from /home/erichst/oorexxbuild/611retail/bin/librexx.so.5.0.0
No symbol table info available.
#2 0x00007ffff7b1a6a8 in NormalSegmentSet::NormalSegmentSet(MemoryObject*) ()
from /home/erichst/oorexxbuild/611retail/bin/librexx.so.5.0.0
No symbol table info available.
#3 0x00007ffff7b28b8d in MemoryObject::initialize(bool) ()
from /home/erichst/oorexxbuild/611retail/bin/librexx.so.5.0.0
No symbol table info available.
#4 0x00007ffff7b628b8 in
Interpreter::startInterpreter(Interpreter::InterpreterStartupMode) () from
/home/erichst/oorexxbuild/611retail/bin/librexx.so.5.0.0
No symbol table info available.
#5 0x00000000004006e9 in main ()
No symbol table info available.
(gdb) disass
Dump of assembler code for function _ZN17MemorySegmentPool10newSegmentEm:
0x00007ffff7b5d4c0 <+0>: push %r13
0x00007ffff7b5d4c2 <+2>: push %r12
0x00007ffff7b5d4c4 <+4>: lea 0xfff(%rsi),%r12
0x00007ffff7b5d4cb <+11>: push %rbp
0x00007ffff7b5d4cc <+12>: push %rbx
0x00007ffff7b5d4cd <+13>: mov %rdi,%rbp
0x00007ffff7b5d4d0 <+16>: mov %rsi,%r13
0x00007ffff7b5d4d3 <+19>: and $0xfffffffffffff000,%r12
0x00007ffff7b5d4da <+26>: sub $0x8,%rsp
0x00007ffff7b5d4de <+30>: jmp 0x7ffff7b5d517
<_ZN17MemorySegmentPool10newSegmentEm+87>
0x00007ffff7b5d4e0 <+32>: mov 0x20(%rbp),%rdx
0x00007ffff7b5d4e4 <+36>: cmp %rdx,%r12
0x00007ffff7b5d4e7 <+39>: jbe 0x7ffff7b5d540
<_ZN17MemorySegmentPool10newSegmentEm+128>
0x00007ffff7b5d4e9 <+41>: mov %r13,%rsi
0x00007ffff7b5d4ec <+44>: mov $0x38,%edi
0x00007ffff7b5d4f1 <+49>: callq 0x7ffff7aa86f0
<_ZN17MemorySegmentPoolnwEmm@plt>
0x00007ffff7b5d4f6 <+54>: mov %rax,%rdi
0x00007ffff7b5d4f9 <+57>: mov %rax,%rbx
0x00007ffff7b5d4fc <+60>: callq 0x7ffff7aab5a0
<_ZN17MemorySegmentPoolC1Ev@plt>
0x00007ffff7b5d501 <+65>: mov 0x2681b8(%rip),%rdi #
0x7ffff7dc56c0
0x00007ffff7b5d508 <+72>: mov %rbx,0x0(%rbp)
0x00007ffff7b5d50c <+76>: mov %rbx,%rsi
0x00007ffff7b5d50f <+79>: mov %rbx,%rbp
0x00007ffff7b5d512 <+82>: callq 0x7ffff7aafe20
<_ZN12MemoryObject15memoryPoolAddedEP17MemorySegmentPool@plt>
=> 0x00007ffff7b5d517 <+87>: mov 0x8(%rbp),%rax
0x00007ffff7b5d51b <+91>: test %rax,%rax
0x00007ffff7b5d51e <+94>: je 0x7ffff7b5d4e0
<_ZN17MemorySegmentPool10newSegmentEm+32>
0x00007ffff7b5d520 <+96>: cmp (%rax),%r13
0x00007ffff7b5d523 <+99>: ja 0x7ffff7b5d4e0
<_ZN17MemorySegmentPool10newSegmentEm+32>
0x00007ffff7b5d525 <+101>: movq $0x0,0x8(%rbp)
---Type <return> to continue, or q <return> to quit---
At a first glance this seems to be exactly the same instruction as before ..
strange
Erich
On Sat, Jul 9, 2016 at 4:06 PM, Rick McGuire
<object.r...@gmail.com<mailto:object.r...@gmail.com>> wrote:
On Sat, Jul 9, 2016 at 9:42 AM, René Jansen
<rene.vincent.jan...@gmail.com<mailto:rene.vincent.jan...@gmail.com>> wrote:
When specifying CMAKE_BUILD_TYPE=Release the rexx image does not build on
Tumbleweed. It receives a segmentation fault in MemorySegmentPool::newSegment().
This was an opportunity to look into how this image is built. This is what
happens:
utilities/rexximage.cpp calls RexxCreateInterpreterImage() in
api/InterpreterAPI.cpp
==> Interpreter::startInterpreter with SAVE_IMAGE_MODE in
interpreter/runtime/Interpreter.cpp
==> calls memoryObject.initialize(mode == RUN_MODE) in
interpreter/memory/RexxMemory.cpp
==> createImage() which is in interpreter/memory/Setup.cpp sets up
==> interpreter/memory/RexxMemory.cpp MemoryObject::saveImage() saves the image
to a file
When I debug ./rexximage it fails in above call. Compiler is gnu 6.1.1. With
this working on other compilers and other platforms, it might be a compiler
bug; on the other hand, structures might be bigger and we run out of space.
Anyone seen this before?
Reading symbols from ./rexximage...done.
(gdb) run
Starting program: /home/rvjansen/workspace/workspace/build/bin/rexximage
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.23-4.12.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7b5f517 in MemorySegmentPool::newSegment(unsigned long) ()
from /home/rvjansen/workspace/workspace/build/bin/librexx.so.5.0.0
Missing separate debuginfos, use: zypper install
libgcc_s1-debuginfo-6.1.1+r236988-1.6.x86_64
libstdc++6-debuginfo-6.1.1+r236988-1.6.x86_64
(gdb) disassemble
Dump of assembler code for function _ZN17MemorySegmentPool10newSegmentEm:
0x00007ffff7b5f4c0 <+0>: push %r13
0x00007ffff7b5f4c2 <+2>: push %r12
0x00007ffff7b5f4c4 <+4>: lea 0xfff(%rsi),%r12
0x00007ffff7b5f4cb <+11>: push %rbp
0x00007ffff7b5f4cc <+12>: push %rbx
0x00007ffff7b5f4cd <+13>: mov %rdi,%rbp
0x00007ffff7b5f4d0 <+16>: mov %rsi,%r13
0x00007ffff7b5f4d3 <+19>: and $0xfffffffffffff000,%r12
0x00007ffff7b5f4da <+26>: sub $0x8,%rsp
0x00007ffff7b5f4de <+30>: jmp 0x7ffff7b5f517
<_ZN17MemorySegmentPool10newSegmentEm+87>
0x00007ffff7b5f4e0 <+32>: mov 0x20(%rbp),%rdx
0x00007ffff7b5f4e4 <+36>: cmp %rdx,%r12
0x00007ffff7b5f4e7 <+39>: jbe 0x7ffff7b5f540
<_ZN17MemorySegmentPool10newSegmentEm+128>
0x00007ffff7b5f4e9 <+41>: mov %r13,%rsi
0x00007ffff7b5f4ec <+44>: mov $0x38,%edi
0x00007ffff7b5f4f1 <+49>: callq 0x7ffff7ab0530
<_ZN17MemorySegmentPoolnwEmm@plt>
0x00007ffff7b5f4f6 <+54>: mov %rax,%rdi
0x00007ffff7b5f4f9 <+57>: mov %rax,%rbx
0x00007ffff7b5f4fc <+60>: callq 0x7ffff7ab33a0
<_ZN17MemorySegmentPoolC1Ev@plt>
0x00007ffff7b5f501 <+65>: mov 0x2671b8(%rip),%rdi # 0x7ffff7dc66c0
0x00007ffff7b5f508 <+72>: mov %rbx,0x0(%rbp)
0x00007ffff7b5f50c <+76>: mov %rbx,%rsi
0x00007ffff7b5f50f <+79>: mov %rbx,%rbp
0x00007ffff7b5f512 <+82>: callq 0x7ffff7ab7c10
<_ZN12MemoryObject15memoryPoolAddedEP17MemorySegmentPool@plt>
If this is the location of the trap, then it looks like an optimizer bug to me.
The generated code doesn't seem to correspond to the source code at all. Note
that the call to new MemorySegmentPool happens after the call to
MemoryObject.memoryPoolAdded(), which is completely out of order since the
value returned from new MemorySegmentPool is the value that gets passed to
memoryPoolAdded. This generated sequence doesn't make any sense at all!
The only thing I can suggest is playing around with the structure of the code a
little to see if you can make it go away. However, this looks so bad that I
wonder if this is just the tip of the iceberg. Here's a slightly restructured
bit of code to try out:
size_t segmentSize = Memory::roundPageSize(minSize); /* compute commit size
*/
/* enough space for request */
if (uncommitted >= segmentSize)
{
MemorySegment *newSeg = new (nextAlloc) MemorySegment (segmentSize);
uncommitted -= segmentSize; /* Adjust uncommitted amount */
nextAlloc += segmentSize; /* Adjust to next Allocation addr */
return newSeg;
}
MemorySegmentPool *newPool = new (minSize) MemorySegmentPool;
if (newPool != NULL)
{ /* Did we get a new Pool? */
next = newPool; /* Anchor it to end of chain */
memoryObject.memoryPoolAdded(newPool); // tell the memory object we'v
added a new pool
return newPool->newSegment(minSize);
}
return NULL;
As I was rewriting this, I wonder if the compiler is getting confused by the
test of the newPool after the new. A new operator is not supposed to return a
NULL value, so perhaps the compiler just got confused by how this was handled.
I just double checked and this new operator raises an error that will not
return to this point if there is an allocation failure, so that little bit of
logic doesn't make any sense. This reduces the logic to this:
MemorySegmentPool *newPool = new (minSize) MemorySegmentPool;
next = newPool; /* Anchor it to end of chain */
memoryObject.memoryPoolAdded(newPool); // tell the memory object we'v
added a new pool
return newPool->newSegment(minSize);
Rick
=> 0x00007ffff7b5f517 <+87>: mov 0x8(%rbp),%rax
0x00007ffff7b5f51b <+91>: test %rax,%rax
0x00007ffff7b5f51e <+94>: je 0x7ffff7b5f4e0
<_ZN17MemorySegmentPool10newSegmentEm+32>
0x00007ffff7b5f520 <+96>: cmp (%rax),%r13
0x00007ffff7b5f523 <+99>: ja 0x7ffff7b5f4e0
<_ZN17MemorySegmentPool10newSegmentEm+32>
0x00007ffff7b5f525 <+101>: movq $0x0,0x8(%rbp)
0x00007ffff7b5f52d <+109>: add $0x8,%rsp
0x00007ffff7b5f531 <+113>: pop %rbx
0x00007ffff7b5f532 <+114>: pop %rbp
0x00007ffff7b5f533 <+115>: pop %r12
0x00007ffff7b5f535 <+117>: pop %r13
0x00007ffff7b5f537 <+119>: retq
0x00007ffff7b5f538 <+120>: nopl 0x0(%rax,%rax,1)
0x00007ffff7b5f540 <+128>: mov 0x10(%rbp),%rax
I set the OpenSUSE build back to non-optimizing.
best regards,
René.
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net<mailto:Oorexx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net<mailto:Oorexx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
