[shared_Ptr] [1.34] URGENT: Outstanding HP-UX / itanium bug
Folks we still haven't solved the outstanding issue summarised here: http://lists.boost.org/boost-users/2005/12/15692.php Defining BOOST_SP_USE_PTHREADS is at least a workaround. Should I apply this to Boost.Config or should the sp_counted_base.hpp logic be altered (to keep everything in one place)? Or does anyone believe they have a fix for the assembly code in time for 1.34? Thanks, John.
John Maddock wrote:
Folks we still haven't solved the outstanding issue summarised here: http://lists.boost.org/boost-users/2005/12/15692.php
Defining BOOST_SP_USE_PTHREADS is at least a workaround. Should I apply this to Boost.Config or should the sp_counted_base.hpp logic be altered (to keep everything in one place)? Or does anyone believe they have a fix for the assembly code in time for 1.34?
Can you try the attached patch? If it doesn't work, I'm out of ideas. If it works, we need to regression test on the other IA64 platforms, though.
Can you try the attached patch? If it doesn't work, I'm out of ideas. If it works, we need to regression test on the other IA64 platforms, though.
No joy: bash-3.00$ c++ -g -I../../../ shared_ptr_test.cpp bash-3.00$ gdb a.out HP gdb 5.3.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 5.3.0 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. (gdb) run Starting program: /house/maddock/libs/smart_ptr/test/a.out warning: Load module /usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/../../../libstdc ++.so has been stripped. Debugging information is not available. Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x40601e1 in boost::detail::atomic_decrement (pw=0x40014bd4) at sp_counted_base_gcc_ia64.hpp:52 warning: Compilation directory is not absolute; could result in incorrect behavi or. Please report to HP. 52 "p7"); (gdb) bt #0 0x40601e1 in boost::detail::atomic_decrement (pw=0x40014bd4) at sp_counted_base_gcc_ia64.hpp:52 #1 0x4060010 in boost::detail::sp_counted_base::release (this=0x40014bd0) at sp_counted_base_gcc_ia64.hpp:127 #2 0x405ff90 in boost::detail::shared_count::~shared_count (this=0x7ffff3e4) at shared_count.hpp:205 #3 0x4060310 in boost::shared_ptr<int>::~shared_ptr (this=0x7ffff3e0) at shared_ptr_test.cpp:61 #4 0x4064ef0 in void n_constructors::pc0_test<int> (p=0x0) at shared_ptr_test.cpp:141 #5 0x402e280:0 in n_constructors::pointer_constructor () at shared_ptr_test.cpp:146 #6 0x40441a0:0 in n_constructors::test () at shared_ptr_test.cpp:1141 #7 0x405f140:0 in main () at shared_ptr_test.cpp:3211 BTW you can try this out for yourself on the HP testdrive machine. John.
John Maddock wrote:
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x40601e1 in boost::detail::atomic_decrement (pw=0x40014bd4) at sp_counted_base_gcc_ia64.hpp:52
The problem is that in __asm__ (" fetchadd4.rel %0=[%2],-1 ;; \n" the %2 register (r15 in my test) contains 0x40014bd4, while the address of *pw is actually 0x2000000040014bd4. Apparently g++ needs to be informed of the fact that %2 is an address register, not a data register. Now I only need to find out how to do that.
Peter Dimov wrote:
John Maddock wrote:
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x40601e1 in boost::detail::atomic_decrement (pw=0x40014bd4) at sp_counted_base_gcc_ia64.hpp:52
The problem is that in
__asm__ (" fetchadd4.rel %0=[%2],-1 ;; \n"
the %2 register (r15 in my test) contains 0x40014bd4, while the address of *pw is actually 0x2000000040014bd4. Apparently g++ needs to be informed of the fact that %2 is an address register, not a data register. Now I only need to find out how to do that.
I fixed it. shared_ptr_test with -O0 -g still segfaults on td176, but this has nothing to do with the inline asm, as the same fault occurs with -DBOOST_SP_DISABLE_THREADS. shared_ptr_test -O2 works fine, as does smart_ptr_test. I tested the fix on the other IA64 testdrives as well, all seem to work. Committed to trunk. OK to commit to branch?
"Peter Dimov" <pdimov@mmltd.net> writes:
Peter Dimov wrote:
John Maddock wrote:
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x40601e1 in boost::detail::atomic_decrement (pw=0x40014bd4) at sp_counted_base_gcc_ia64.hpp:52
The problem is that in
__asm__ (" fetchadd4.rel %0=[%2],-1 ;; \n"
the %2 register (r15 in my test) contains 0x40014bd4, while the address of *pw is actually 0x2000000040014bd4. Apparently g++ needs to be informed of the fact that %2 is an address register, not a data register. Now I only need to find out how to do that.
I fixed it. shared_ptr_test with -O0 -g still segfaults on td176, but this has nothing to do with the inline asm, as the same fault occurs with -DBOOST_SP_DISABLE_THREADS. shared_ptr_test -O2 works fine, as does smart_ptr_test. I tested the fix on the other IA64 testdrives as well, all seem to work. Committed to trunk.
OK to commit to branch?
Bugfixes on the release branch are always OK until the release manager freezes it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peter Dimov <pdimov <at> mmltd.net> writes: <snip>
I fixed it. shared_ptr_test with -O0 -g still segfaults on td176, but this has nothing to do with the inline asm, as the same fault occurs
Do you know why this test still fails ? Thanks, Michael Haubenwallner
Michael Haubenwallner wrote:
Peter Dimov <pdimov <at> mmltd.net> writes: <snip>
I fixed it. shared_ptr_test with -O0 -g still segfaults on td176, but this has nothing to do with the inline asm, as the same fault occurs
Do you know why this test still fails ?
I have no idea. :-) It could be a compiler bug.
I cannot reproduce it on B.11.23 with g++ 3.4.3. I'm using yesterday's 1.34 tarball: bash-3.00$ uname -a HP-UX granite B.11.23 U ia64 2207888362 unlimited-user license bash-3.00$ g++ --version g++ (GCC) 3.4.3 bash-3.00$ g++ -I../../../ -g smart*.cpp && a.out UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed OK UDT with value 54321 being destroyed UDT with value 333 being destroyed UDT with value 222 being destroyed UDT with value 111 being destroyed UDT with value 333222111 being destroyed No errors detected. bash-3.00$ ----- Original Message ----- From: "Peter Dimov" <pdimov@mmltd.net> To: <boost@lists.boost.org> Sent: Thursday, September 07, 2006 4:18 PM Subject: Re: [boost] [shared_Ptr] [1.34] URGENT: Outstanding HP-UX/itaniumbug
Michael Haubenwallner wrote:
Peter Dimov <pdimov <at> mmltd.net> writes: <snip>
I fixed it. shared_ptr_test with -O0 -g still segfaults on td176, but this has nothing to do with the inline asm, as the same fault occurs
Do you know why this test still fails ?
I have no idea. :-) It could be a compiler bug. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
I cannot reproduce it on B.11.23 with g++ 3.4.3. I'm using yesterday's 1.34 tarball:
bash-3.00$ uname -a HP-UX granite B.11.23 U ia64 2207888362 unlimited-user license bash-3.00$ g++ --version g++ (GCC) 3.4.3 bash-3.00$ g++ -I../../../ -g smart*.cpp && a.out
Can you please try the same with shared_ptr_test.cpp instead of smart_ptr_test.cpp? [...]
Peter Dimov <pdimov <at> mmltd.net> writes: <snip>
I fixed it. shared_ptr_test with -O0 -g still segfaults on td176, but this has nothing to do with the inline asm, as the same fault occurs
It segfaults, with and without -O0: Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x408b831 in boost::detail::sp_counted_impl_pd<n_report_2::foo*,n_report_2::deleter>::boost::detail::sp_counted_impl_pd<n_report_2:: foo*,n_report_2::deleter> ( this=0x40014c30, p=0x40014bd0, d={<No data fields>}) at sp_counted_impl.hpp:140 ----- Original Message ----- From: "Peter Dimov" <pdimov@mmltd.net> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Thursday, September 07, 2006 6:43 PM Subject: Re: [boost] [shared_Ptr] [1.34] URGENT: Outstanding HP-UX/itaniumbug
Boris Gubenko wrote:
I cannot reproduce it on B.11.23 with g++ 3.4.3. I'm using yesterday's 1.34 tarball:
bash-3.00$ uname -a HP-UX granite B.11.23 U ia64 2207888362 unlimited-user license bash-3.00$ g++ --version g++ (GCC) 3.4.3 bash-3.00$ g++ -I../../../ -g smart*.cpp && a.out
Can you please try the same with shared_ptr_test.cpp instead of smart_ptr_test.cpp?
[...]
Peter Dimov <pdimov <at> mmltd.net> writes: <snip>
I fixed it. shared_ptr_test with -O0 -g still segfaults on td176, but this has nothing to do with the inline asm, as the same fault occurs
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
It segfaults, with and without -O0:
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x408b831 in boost::detail::sp_counted_impl_pd<n_report_2::foo*,n_report_2::deleter>::boost::detail::sp_counted_impl_pd<n_report_2:: foo*,n_report_2::deleter> ( this=0x40014c30, p=0x40014bd0, d={<No data fields>}) at sp_counted_impl.hpp:140
The relevant portion of shared_ptr_test seems to be n_report_2, reproduced below; it seems that the fault is occuring at the very first line of test(). I really can't see anything wrong with it; the test passes on every other platform. class foo { public: void setWeak(boost::shared_ptr<foo> s) { w = s; } private: boost::weak_ptr<foo> w; }; class deleter { public: deleter(): lock(0) { } ~deleter() { BOOST_TEST(lock == 0); } void operator() (foo * p) { ++lock; delete p; --lock; } private: int lock; }; void test() { boost::shared_ptr<foo> s(new foo, deleter()); s->setWeak(s); s.reset(); }
I really can't see anything wrong with it; the test passes on every other platform.
It does, including the very same machine with aCC6. In fact, with aCC6, smart_ptr is all green. Why is this failure a concern for 1.34? Is g++ on HP-UX ia64 a release platform? Boris ----- Original Message ----- From: "Peter Dimov" <pdimov@mmltd.net> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Thursday, September 07, 2006 7:02 PM Subject: Re: [boost] [shared_Ptr] [1.34] URGENT: Outstanding HP-UX/itaniumbug
Boris Gubenko wrote:
It segfaults, with and without -O0:
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x408b831 in boost::detail::sp_counted_impl_pd<n_report_2::foo*,n_report_2::deleter>::boost::detail::sp_counted_impl_pd<n_report_2:: foo*,n_report_2::deleter> ( this=0x40014c30, p=0x40014bd0, d={<No data fields>}) at sp_counted_impl.hpp:140
The relevant portion of shared_ptr_test seems to be n_report_2, reproduced below; it seems that the fault is occuring at the very first line of test(). I really can't see anything wrong with it; the test passes on every other platform.
class foo { public:
void setWeak(boost::shared_ptr<foo> s) { w = s; }
private:
boost::weak_ptr<foo> w; };
class deleter { public:
deleter(): lock(0) { }
~deleter() { BOOST_TEST(lock == 0); }
void operator() (foo * p) { ++lock; delete p; --lock; }
private:
int lock; };
void test() { boost::shared_ptr<foo> s(new foo, deleter()); s->setWeak(s); s.reset(); }
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, 2006-09-07 at 19:10 -0400, Boris Gubenko wrote:
I really can't see anything wrong with it; the test passes on every other platform.
It does, including the very same machine with aCC6. In fact, with aCC6, smart_ptr is all green.
Why is this failure a concern for 1.34? Is g++ on HP-UX ia64 a release platform?
Huh, yes! If not, we are unable to deliver our product on ia64-hpux for many more months and have to keep using hppa-hpux. Does aCC fully support boost already ? -haubi-
Boris
----- Original Message ----- From: "Peter Dimov" <pdimov@mmltd.net> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Thursday, September 07, 2006 7:02 PM Subject: Re: [boost] [shared_Ptr] [1.34] URGENT: Outstanding HP-UX/itaniumbug
Boris Gubenko wrote:
It segfaults, with and without -O0:
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x408b831 in boost::detail::sp_counted_impl_pd<n_report_2::foo*,n_report_2::deleter>::boost::detail::sp_counted_impl_pd<n_report_2:: foo*,n_report_2::deleter> ( this=0x40014c30, p=0x40014bd0, d={<No data fields>}) at sp_counted_impl.hpp:140
The relevant portion of shared_ptr_test seems to be n_report_2, reproduced below; it seems that the fault is occuring at the very first line of test(). I really can't see anything wrong with it; the test passes on every other platform.
class foo { public:
void setWeak(boost::shared_ptr<foo> s) { w = s; }
private:
boost::weak_ptr<foo> w; };
class deleter { public:
deleter(): lock(0) { }
~deleter() { BOOST_TEST(lock == 0); }
void operator() (foo * p) { ++lock; delete p; --lock; }
private:
int lock; };
void test() { boost::shared_ptr<foo> s(new foo, deleter()); s->setWeak(s); s.reset(); }
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz mailto:michael.haubenwallner@salomon.at http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html
Michael Haubenwallner wrote:
Why is this failure a concern for 1.34? Is g++ on HP-UX ia64 a release platform?
Huh, yes! If not, we are unable to deliver our product on ia64-hpux for many more months and have to keep using hppa-hpux.
Have you encountered the problem in your code? It could be limited to shared_ptr_test.cpp. In my tests, it segfaulted even with -DBOOST_SP_DISABLE_THREADS, so it's not the platform-specific atomics that cause it.
On Fri, 2006-09-08 at 14:07 +0300, Peter Dimov wrote:
Michael Haubenwallner wrote:
Why is this failure a concern for 1.34? Is g++ on HP-UX ia64 a release platform?
Huh, yes! If not, we are unable to deliver our product on ia64-hpux for many more months and have to keep using hppa-hpux.
Have you encountered the problem in your code? It could be limited to shared_ptr_test.cpp. In my tests, it segfaulted even with -DBOOST_SP_DISABLE_THREADS, so it's not the platform-specific atomics that cause it.
When we decided to use gcc on hpux, aCC did not support all those boost libs we are using. Now i'm just surprised to hear that gcc on ia64-hpux might not be a release platform for boost. Well, first it looked like that whe have a very similar problem with our code than in the shared_ptr_test (did not dig deeper into both yet): Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x5c17e30 in <unknown_procedure> () (gdb) But now, as the shared_ptr_test works with -O2 (at least for me), I just tried our code with -O2, and it still does not work. So it also could be another (gcc?)problem than for the shared_ptr_test. Btw. I'm using a self-compiled gcc-3.4.5 with a few selected patches, and GNU-as but native ld. -haubi- PS: Where is those boost test page ? I have seen it before, but cannot find it anymore... -- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz mailto:michael.haubenwallner@salomon.at http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html
Michael Haubenwallner wrote:
Well, first it looked like that whe have a very similar problem with our code than in the shared_ptr_test (did not dig deeper into both yet):
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x5c17e30 in <unknown_procedure> () (gdb)
But now, as the shared_ptr_test works with -O2 (at least for me), I just tried our code with -O2, and it still does not work. So it also could be another (gcc?)problem than for the shared_ptr_test.
Does it still not work with BOOST_SP_DISABLE_THREADS or BOOST_SP_USE_PTHREADS defined? If so, it's a general problem, not caused by the platform-specific atomics; it could be a compiler backend bug, and should probably be reported to the GCC Bugzilla. Can you try a 4.x g++? It might have even been fixed. The Boost test pages are at http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/ linked from the main page, top right corner.
On Fri, 2006-09-08 at 15:52 +0300, Peter Dimov wrote:
Michael Haubenwallner wrote:
Well, first it looked like that whe have a very similar problem with our code than in the shared_ptr_test (did not dig deeper into both yet):
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x5c17e30 in <unknown_procedure> () (gdb)
But now, as the shared_ptr_test works with -O2 (at least for me), I just tried our code with -O2, and it still does not work. So it also could be another (gcc?)problem than for the shared_ptr_test.
Does it still not work with BOOST_SP_DISABLE_THREADS or BOOST_SP_USE_PTHREADS defined? If so, it's a general problem, not caused by the platform-specific atomics; it could be a compiler backend bug, and should probably be reported to the GCC Bugzilla. Can you try a 4.x g++? It might have even been fixed.
shared_ptr_test still fails with HP's gcc-4.1.1 (depot, installs to /opt/hp-gcc). But curious, with self-built gcc-4.1.1 (using GNU-as from binutils 2.16.1, native ld), shared_ptr_test works both with -O2 and -O0. Now going for the application test.
The Boost test pages are at
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/
linked from the main page, top right corner.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
PS: Where is those boost test page ?
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/su... ----- Original Message ----- From: "Michael Haubenwallner" <michael.haubenwallner@salomon.at> To: <boost@lists.boost.org> Sent: Friday, September 08, 2006 8:20 AM Subject: Re: [boost] [shared_Ptr] [1.34] URGENT: OutstandingHP-UX/itanium bug
On Fri, 2006-09-08 at 14:07 +0300, Peter Dimov wrote:
Michael Haubenwallner wrote:
Why is this failure a concern for 1.34? Is g++ on HP-UX ia64 a release platform?
Huh, yes! If not, we are unable to deliver our product on ia64-hpux for many more months and have to keep using hppa-hpux.
Have you encountered the problem in your code? It could be limited to shared_ptr_test.cpp. In my tests, it segfaulted even with -DBOOST_SP_DISABLE_THREADS, so it's not the platform-specific atomics that cause it.
When we decided to use gcc on hpux, aCC did not support all those boost libs we are using. Now i'm just surprised to hear that gcc on ia64-hpux might not be a release platform for boost.
Well, first it looked like that whe have a very similar problem with our code than in the shared_ptr_test (did not dig deeper into both yet):
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x5c17e30 in <unknown_procedure> () (gdb)
But now, as the shared_ptr_test works with -O2 (at least for me), I just tried our code with -O2, and it still does not work. So it also could be another (gcc?)problem than for the shared_ptr_test. Btw. I'm using a self-compiled gcc-3.4.5 with a few selected patches, and GNU-as but native ld.
-haubi- PS: Where is those boost test page ? I have seen it before, but cannot find it anymore... -- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz mailto:michael.haubenwallner@salomon.at http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Michael Haubenwallner wrote:
Does aCC fully support boost already ?
No, not yet. We are working on it. See boost test page for the current status (Full View). It may be, that the boost libraries you are using are all green. Boris ----- Original Message ----- From: "Michael Haubenwallner" <michael.haubenwallner@salomon.at> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Friday, September 08, 2006 5:43 AM Subject: Re: [boost] [shared_Ptr] [1.34] URGENT: OutstandingHP-UX/itaniumbug
On Thu, 2006-09-07 at 19:10 -0400, Boris Gubenko wrote:
I really can't see anything wrong with it; the test passes on every other platform.
It does, including the very same machine with aCC6. In fact, with aCC6, smart_ptr is all green.
Why is this failure a concern for 1.34? Is g++ on HP-UX ia64 a release platform?
Huh, yes! If not, we are unable to deliver our product on ia64-hpux for many more months and have to keep using hppa-hpux. Does aCC fully support boost already ?
-haubi-
Boris Gubenko wrote:
I really can't see anything wrong with it; the test passes on every other platform.
It does, including the very same machine with aCC6. In fact, with aCC6, smart_ptr is all green.
Why is this failure a concern for 1.34? Is g++ on HP-UX ia64 a release platform?
Just as a clarification. Every known problem is a concern, especially if it's in a core library. If it's not a release platform we might not hold the release for it but that's about the only distinction. Thomas -- Thomas Witt witt@acm.org
--- John Maddock <john@johnmaddock.co.uk> wrote:
Folks we still haven't solved the outstanding issue summarised here: http://lists.boost.org/boost-users/2005/12/15692.php
Defining BOOST_SP_USE_PTHREADS is at least a workaround. Should I apply this to Boost.Config or should the sp_counted_base.hpp logic be altered (to keep everything in one place)? Or does anyone believe they have a fix for the assembly code in time for 1.34?
I am not sure this is relevant, but just in case: Recently I got Boost.Python to work under HP-UX using the native cc/aCC compilers. Before I got all the switches right I had "mysterious" crashes (Abort, Segfault, Bus error). In the end it turned out (thanks to Boris Gubenko!) that the crashes resulted from violating this rule: if you link with -lpthread you have to compile with -mt. I don't know how this applies to g++, but I can imagine that one has to be generally very careful using -mt and -lpthread consistently. Python's configure (Python 2.4.2) definitely doesn't get it right without intervention. I am wondering if the g++ installation may also need intervention. BTW: The smart_ptr_test works fine with HP's aCC compiler on the public testdrive machine. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
participants (7)
-
Boris Gubenko -
David Abrahams -
John Maddock -
Michael Haubenwallner -
Peter Dimov -
Ralf W. Grosse-Kunstleve -
Thomas Witt