SDK 3.0: Compiler bug with std::deque?

When I call std::deque::assign(), I get all kinds of compile-time errors, including internal compiler errors.
Note, however, that this happens only when I compile for the 3.0 device. It does not happen when I compile for the 3.0 simulator, 2.x device or 2.x simulator. In all those other modes it compiles and works just fine. Only when compiling for the 3.0 device, the compiler errors happen.
I'm pretty certain this is a bug in the SDK. Has anyone else noticed this?

Assign is a particularly tricky one. There are two assign methods. One takes two iterators and the other takes a size and value:
template<class InputIterator>
void assign(InputIterator first, InputIterator last);
void assign(size_type n, const T & t);
For whatever reason, the compiler for the 3.0 device is saying "int" and "int *" are the same type. It is instantiation the version with the iterators instead of the second one. This is a typical error you might see on a platform with weak C++ support. I used to have to deal with things like this all the time in the early days of MacOS X.
Unfortunately, the only workaround is to do something else. The following should work:
#include <algorithm>
std::deque<int> values;
std::filln(std::backinserter(values), 10, 1);

Similar Messages

BUG: Oracle Java Compiler bug with anonymous inner classes in constructor

The following code compiles and runs just fine using 1.4.2_07, 1.5.0_07 and 1.6.0_beta2 when compiling and running from the command-line.
It does not run when compiling from JDeveloper 10.1.3.36.73 (which uses the ojc.jar).
When compiled from JDeveloper, the JRE (both the embedded one or the external 1.5.0_07 one) reports the following error:
java.lang.VerifyError: (class: com/ids/arithmeticexpr/Scanner, method: <init> signature: (Ljava/io/Reader;)V) Expecting to find object/array on
stack
Here's the code:
/** lexical analyzer for arithmetic expressions.
Fixes the lookahead problem for TT_EOL.
public class Scanner extends StreamTokenizer
/** kludge: pushes an anonymous Reader which inserts
a space after each newline.
public Scanner( Reader r )
super( new FilterReader( new BufferedReader( r ) )
protected boolean addSpace; // kludge to add space after \n
public int read() throws IOException
int ch = addSpace ? ' ' : in.read();
addSpace = ch == '\n';
return ch;
public static void main( String[] args )
Scanner scanner = new Scanner( new StringReader("1+2") ); // !!!
Removing the (implicit) reference to 'this' in the call to super() by passing an instance of a static inner class 'Kludge' instead of the anonymous subclass of FilterReader fixes the error. The code will then run even when compiled with ojc. There seems to be a bug in ojc concerning references to the partially constructed object (a bug which which is not present in the reference compilers.)
-- Sebastian

Thanks Sebastian, I filed a bug for OJC, and I'll look at the Javac bug. Either way, OJC should either give an error or create correct code.
Keimpe Bronkhorst
JDev Team

Compiler bug with generics and private inner classes

There appears to be a bug in the sun java compiler. This problem was reported against eclipse and the developers their concluded that it must be a problem with javac.
Idea also seems to compile the example below. I couldn't find a bug report in the sun bug database. Can somebody tell me if this is a bug in javac and if there is a bug report for it.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=185422
public class Foo <T>{
private T myT;
public T getT() {
return myT;
public void setT(T aT) {
myT = aT;
public class Bar extends Foo<Bar.Baz> {
public static void main(String[] args) {
Bar myBar = new Bar();
myBar.setT(new Baz());
System.out.println(myBar.getT().toString());
private static class Baz {
@Override
public String toString() {
return "Baz";
Eclipse compiles and runs the code even though the Baz inner class is private.
javac reports:
Bar.java:1: Bar.Baz has private access in Bar
public class Bar extends Foo<Bar.Baz>
^
1 error

As I said in my original post its not just eclipse that thinks the code snippet is compilable. IntelliJ Idea also parses it without complaining. I haven't looked at the java language spec but intuitively I see no reason why the code should not compile. I don't think eclipse submitting bug reports to sun has anything to do with courage. I would guess they just couldn't be bothered.

Studio 10 compiler bug with example

The following example produces a crash on Solaris Intel with Sun Studio 10, but works with Workshop 6 update 2.
This example describes the simple case of using Xerces-c C++'s DefaultHandler class from a shared library.
Running "main" will crash using Sun Studio 10 on Solaris 10 x86 but exits normally on Solaris any Sparc.
Execute the following commands to build the example:
CC -mt -G -g -KPIC -c t1.cpp -o t1.o -g -fns -features=rtti -lpthread
CC -mt -G -g -o libt1.so t1.o -z defs -lCrun -lc
CC -mt -G -g -KPIC -c t2.cpp -o t2.o -g -fns -features=rtti -lpthread
CC -mt -G -g -o libt2.so t2.o -z defs -lCrun -lc libt1.so
CC -mt -g -o main main.cpp -features=rtti -Bdynamic libt2.so
Contents of main.cpp:
#include "t2.h"
#include "unistd.h"
int main(void)
CT2Start* t2start = new CT2Start();
t2start->Start();
delete t2start;
return 0;
Contents of t1.h:
class CT1A
public:
virtual void T1(void) = 0;
class CT1B
public:
class CT1 :
public CT1B,
public CT1A
public:
virtual void T1(void);
inline void CT1::T1(void)
class CT1Start
public:
void Start(CT1A* t1a);
Contents of t1.cpp:
#include "t1.h"
class CDoSomething
public:
void DoSomething(void)
void CT1Start::Start(CT1A* t1a)
CDoSomething* doSomething = new CDoSomething();
t1a->T1();
doSomething->DoSomething();
delete doSomething;
Contents of t2.h:
#include "t1.h"
class CT2 : public CT1
public:
virtual void T1(void);
class CT2Start
public:
void Start(void);
Contents of t2.cpp:
#include "t2.h"
void CT2::T1(void)
void CT2Start::Start(void)
CT2* t2 = new CT2();
CT1Start* t1start = new CT1Start();
t1start->Start(t2);
delete t1start;
delete t2;
}

Your build script has some problems. You are using the -G option when you intend to compile to a .o, but -G is for creating a shared library. There are problems with library dependencies . You build libt2.so with a dependency on libt1.so, but libt1 is does not satisfy any references in libt2, so the dependency has no effect. You need to list libt1 when building the executable. (Maybe in the real program libt1 is needed by libt2.)
You don't need to use LD_LIBRARY_PATH at all. You should instead build a run-path into the executable, using the -R option. For reasons why you should never set LD_LIBRARY_PATH, see this blog entry:
http://blogs.sun.com/roller/page/rie?anchor=tt_ld_library_path_tt
Here is a corrected build script:
CC -mt -c -g -KPIC t1.cpp
CC -mt -G -g -o libt1.so t1.o -z defs -lCrun -lpthread -lc
CC -mt -c -g -KPIC t2.cpp
CC -mt -G -g -o libt2.so t2.o -z defs libt1.so -lCrun -lpthread -lc
CC -mt -g -o main main.cpp libt1.so libt2.so -lpthread -R.
I have omitted the -features=rtti, since it is the default, and has no effect. I also omitted the -fns. You can put it back if you don't want standard floating-point results.
I verified the problem using the original release of Studio 10. Using the current patched version, the code runs as originally written.
You can get the current patches here:
http://developers.sun.com/prodtech/cc/downloads/patches/index.html

Workshop 6 Bug with STLport hash_map operator []

Using hash_map<string, string>:operator[] in a debug build crashes; in release, it doesn't. This must be a compiler bug, yes? Here's how to reproduce it.
<PRE>
[valhalla:~/test] $ cat t.c
#include <string>
#include <hash_map>
using namespace std;
main()
hash_map<string, string> m;
m["stl"] = "port";
string s = m["stl"];
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -I/apps/stlport-4.5.3/stlport -L/apps/stlport-4.5.3/lib -R/apps/stlport-4.5.3/lib -lstlport_sunpro t.c
[valhalla:~/test] $ a.out
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -g -I/apps/stlport-4.5.3/stlport -L/apps/stlport-4.5.3/lib -R/apps/stlport-4.5.3/lib -lstlport_sunpro t.c
[valhalla:~/test] $ a.out
Bus Error (core dumped)
[valhalla:~/test] $ dbx -q a.out core
core file header read successfully
program terminated by signal BUS (invalid address alignment)
Current function is STL::_stl_delete
99 inline void STLPCALL __stl_delete(void* __p) { ::operator delete(__p); }
(dbx) where
[1] freeunlocked(0xffbee657, 0xff23a000, 0xffbee657, 0xff23a000, 0x237e8, 0xff1c291c), at 0xff1c2974
[2] free(0xffbee657, 0xffbee5d4, 0xffbee658, 0xffbee5e2, 0xffbee5e1, 0xff19bb88), at 0xff1c2924
[3] operator delete(0xffbee657, 0xffbee658, 0xffbee657, 0xff37e540, 0x13bb0, 0x1ee00), at 0xff3636f8
=>[4] STL::_stl_delete(__p = 0xffbee657), line 99 in "new"
[5] STL::_node_alloc<true,0>::deallocate(__p = 0xffbee657, __n = 4347225U), line 253 in "_alloc.h"
[6] STL::allocator<char>::deallocate(this = 0xffbee5b0, _p = 0xffbee657 "", __n = 4347225U), line 360 in "_alloc.h"
[7] STL::STLP_alloc_proxy<char*,char,_STL::allocator<char> >::deallocate(this = 0xffbee5b0, __p = 0xffbee657 "", __n = 4347225U), line 506 in "_alloc.h"
[8] STL::String_base<char,_STL::allocator<char> >::_M_deallocate_block(this = 0xffbee5a8), line 124 in "_string.h"
[9] STL::String_base<char,_STL::allocator<char> >::~_String_base(this = 0xffbee5a8), line 135 in "_string.h"
[10] STL::basicstring<char,_STL::char_traits<char>,_STL::allocator<char> >::~basic_string(this = 0xffbee5a8), line 302 in "_string.h"
[11] STL::hashmap<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::hash<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >,_STL::equal_to<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >,_STL::allocator<_STL::pair<const STL::basicstring<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > > > >::operator[](this = 0xffbee680, __key = CLASS), line 186 in "_hash_map.h"
[12] main(), line 8 in "t.c"
(dbx) exit
[valhalla:~/test] $ exit
exit
[valhalla:~/test] $ which CC
/apps/SUNWspro64/bin/CC
[valhalla:~/test] $ CC -V
CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-09 2002/07/08
[valhalla:~/test] $ uname -a
SunOS valhalla 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Blade-100
</PRE>
STLport places all of its classes in its own _STL namespace, so there is no concern for name collision with std types that come with the Sun compiler.
Any ideas?
Regards,
Jason

I found out this is compiler bug with Forte 6 that ocurrs when inlining is enabled and temporaries are used in conditional expressions with the ?: operator, e.g.,
[valhalla:~/test] $ cat tt.c
#include <iostream>
#include <stdlib.h>
using namespace std;
struct X {
X() { cout << "X ctor" << endl; }
~X() { cout << "X dtor" << endl; }
int foo() { return 1; }
struct Y {
Y() { cout << "Y ctor" << endl; }
~Y() { cout << "Y dtor" << endl; }
int foo() { return 1; }
inline int foo(int i)
return i ?
X().foo() :
Y().foo() ;
main(int, char **argv)
return foo(atoi(argv[1]));
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -g tt.c
[valhalla:~/test] $ a.out 1
X ctor
X dtor
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC tt.c
[valhalla:~/test] $ a.out 1
X ctor
Y dtor
X dtor
[valhalla:~/test] $ g++ tt.c
[valhalla:~/test] $ a.out 1
X ctor
X dtor

Libumem complains on redzone violation in std::deque even with latest patch

HW: e2900 (USIV+ cpus), 5.10 Generic_118833-24
I've applied the latest libCstd patch 119963-08
SW:
CC +w -fast -erroff=hidef -V -PIC -mt -xtarget=ultra3 -xarch=v9a sunBugReportDeque.cc
CC: Sun C++ 5.8 Patch 121017-08 2006/12/06
cg: Sun Compiler Common 11 Patch 120760-11 2006/10/18
The attached code fails, when running under libumem on said machine
If I change the deque to a list, everything works smoothly, suggesting there is still something fishy inside the deque allocate/deallocate functions. I could not reproduce the fault on my (single-CPU) workstation, but on the 2900 it crashes immediately.
// file: sunBugReportDeque.cc
#ifndef DEPEND
#include <deque>
#include <exception>
#include <functional>
#include <iostream>
#include <list>
#include <sstream>
#include <stdexcept>
#include <stdio.h>     // sprintf
#include <synch.h>
#include <sys/errno.h> // ETIME
#include <sys/time.h> // gettimeofday
#include <thread.h>
#include <time.h>
#include <unistd.h>
#include <vector>
#endif
using namespace std;
#define ENSURE(expr) do { int rc = expr ; \
        if (rc != 0) \
            char buf[800]; \
            snprintf(buf, sizeof(buf), "%s: unexpected rc: %d", #expr, rc); \
            buf[sizeof(buf)-1] = '\0'; \
            throw std::logic_error(buf);\
    } while(0)
/** A simple mutex implementation. */
class Mutex
    friend class Condition; // needs access to my mutex
public:
    Mutex() {
        ENSURE(::mutex_init(&_impl, 0, 0));
     * Destructor.
    ~Mutex() {
        ENSURE(::mutex_destroy(&_impl));
    void acquire() {
        ENSURE(::mutex_lock(&_impl));
    void acquireRead() { this->acquire(); }
    void acquireWrite() { this->acquire(); }
    void release() {
        ENSURE(::mutex_unlock(&_impl));
    void releaseRead() { this->release(); }
    void releaseWrite() { this->release(); }
    inline bool tryAcquire();
    bool tryAcquireRead() { return this->tryAcquire(); }
    bool tryAcquireWrite() { return this->tryAcquire(); }
private:
    mutex_t _impl;
bool
Mutex::tryAcquire()
while(true) {
    int rc = ::mutex_trylock(&_impl);
    switch (rc)
    case 0: // ok, we got it...
        return true;
    case EBUSY: // nope, it was already taken...
        return false;
    case EINTR: // fork or signal, try again...
        continue;
    case EINVAL: // The rest is faults, should not happend...
    case EFAULT:
        throw std::invalid_argument("Internal error, illegal adress");
    default:
        char msg[800];
        ::sprintf(msg, "::mutex_trylock: Unrecognized rc: %d", rc);
        throw std::logic_error(msg);
/** A simple condition variable implementation. */
class Condition
public:
    enum WaitStatus { TIMEOUT, SIGNALED };
    Condition(Mutex &m) : _m(m) { ENSURE(::cond_init(&_impl, 0, 0)); }
    ~Condition() { ENSURE(::cond_destroy(&_impl)); }
    void signal() { ENSURE(::cond_signal(&_impl)); }
    void signalAll() { ENSURE(::cond_broadcast(&_impl)); }
    inline void wait();
    inline WaitStatus wait(unsigned long ms);
private:
    Condition(const Condition&);
    const Condition& operator=(const Condition&);
    cond_t _impl;
    Mutex &_m;
void
Condition::wait()
    while(true) {
        int rc = ::cond_wait(&_impl, &_m._impl);
        switch (rc)
        case 0: // NoOp, all is well...
            return;
        case EFAULT:
            throw std::invalid_argument("Internal error, illegal adress");
        case EINTR: // fork or signal, we should still be sleeping
            continue;
        default:
            char msg[50];
            sprintf(msg, "::cond_wait: Unrecognized rc: %d", rc);
            throw std::logic_error(msg);
Condition::WaitStatus
Condition::wait(unsigned long millis)
    struct timeval tp;
    timestruc_t to;
    if(gettimeofday(&tp, 0))
    { // failed, use time() instead
        to.tv_sec = ::time(NULL) + millis / 1000;
        to.tv_nsec = (millis % 1000) * 1000000; // 1e6 nanos-per-milli
    else
    { // Ok, calculate when to wake up..
        to.tv_sec = tp.tv_sec + millis/1000;
        to.tv_nsec = tp.tv_usec*1000 + (millis%1000)*1000000;
        if(to.tv_nsec >= 1000000000)
            to.tv_nsec -= 1000000000;
            to.tv_sec++;
    while(true) {
        int rc = ::cond_timedwait(&_impl, &_m._impl, &to);
        switch (rc)
        case 0: // NoOp, all is well... Someone told ut to wake up before timeout...
            return SIGNALED;
        case EFAULT:
            throw std::invalid_argument("Internal error, illegal adress");
        case EINTR: // fork or signal, we should still be sleeping
            continue;
        case ETIME:
        case ETIMEDOUT:
            return TIMEOUT;
        default:
            char msg[50];
            sprintf(msg, "::cond_timedwait: Unrecognized rc: %d", rc);
            throw std::logic_error(msg);
/** Suitable for grabbing a mutex exclusively. The mutex will be
* released when the object dies.
template <class Lock>
class Guard
public:
    Guard(Lock &l) : _l(l) { _l.acquire(); }
    ~Guard() { _l.release(); }
private:
    Guard(const Guard&);
    const Guard& operator=(const Guard&);
    Lock &_l;
class Timer
public:
    Timer() : _cond(_mutex), _isCancelled(false) { }
    ~Timer() { }
    /** Sleeps the specified no of secs, or until the timer is cancelled. */
    inline void sleep(const int millis);
    /** Cancels the timer. Ongoing sleeps will wakeup, new ones will not block.
    inline void cancel();
    inline bool isCancelled();
protected:
private:
    Timer(const Timer& aTimer);
    Timer& operator=(const Timer& aTimer);
    Mutex     _mutex;
    Condition _cond;
    bool         _isCancelled;
void Timer::sleep(const int millis)
    Guard<Mutex> lock(_mutex);
    if (! _isCancelled) // only wait one turn
        _cond.wait(millis);
void Timer::cancel()
    Guard<Mutex> lock(_mutex);
    _isCancelled = true;
    _cond.signalAll();
bool Timer::isCancelled()
    Guard<Mutex> lock(_mutex);
    return _isCancelled;
// shouldn't this be available in STL somewhere???
template <class T>
struct Predicate : public std::unary_function<T, bool>
    virtual bool operator()(const T &x) const = 0;
/** A simple Producer Consumer Queue implementation. */
template <class T>
class PCQueue
public:
    PCQueue(size_t aMaxLenght)
            : myMaxlength(aMaxLenght),
              myQNotEmpty(myQLock),
              myQNotFull(myQLock){ }
    void push(const T& aT);
    bool tryPush(const T& aT);
    T pop();
    bool tryPop(T& retVal, const unsigned int millis = 0);
    size_t size() const;
    bool isFull() const;
     * Atomically purges (removes) the FIRST element for which the supplied
     * predicate returns true.
    bool purge(const Predicate<T>& pred, T& theItem);
protected:
private:
    typedef Guard<Mutex> MutexGuard;
    std::deque<T>        myQueue;
    mutable Mutex        myQLock;
    Condition            myQNotEmpty;
    Condition            myQNotFull;
    size_t               myMaxlength;
template <class T>
size_t PCQueue<T>::size() const
    MutexGuard g(myQLock);
    return myQueue.size();
template <class T>
void PCQueue<T>::push(const T& aT)
    MutexGuard g(myQLock);
    while (myMaxlength && myQueue.size() >= myMaxlength)
        myQNotFull.wait();
    myQueue.push_back(aT);
    myQNotEmpty.signal();
template <class T>
bool PCQueue<T>::tryPush(const T& aT)
    MutexGuard g(myQLock);
    while (myMaxlength && myQueue.size() >= myMaxlength)
        return false;
    myQueue.push_back(aT);
    myQNotEmpty.signal();
    return true;
template <class T>
T PCQueue<T>::pop()
    MutexGuard g(myQLock);
    T entry;
    while (myQueue.empty())
        myQNotEmpty.wait();
    entry = myQueue.front();
    myQueue.pop_front();
    myQNotFull.signal();
    return entry;
template <class T>
bool PCQueue<T>::tryPop(T& retVal, const unsigned int millis)
    MutexGuard g(myQLock);
    long long start = ::gethrtime();
    long remainder = millis;
    while (remainder > 0 && myQueue.empty())
        myQNotEmpty.wait(remainder);
        remainder = millis - (long)((::gethrtime() - start) / 1000000LL);
    if (myQueue.empty()) // timed out
        return false;
    retVal = myQueue.front();
    myQueue.pop_front();
    myQNotFull.signal();
    return true;
template <class T>
bool PCQueue<T>::isFull() const
    MutexGuard g(myQLock);
    if (myMaxlength == 0) // No limit on the queue
        return false;
    return (myQueue.size() >= myMaxlength) ? true : false;
template <class T>
bool PCQueue<T>::purge(const Predicate<T> &pred, T& theItem)
    MutexGuard g(myQLock);
    for (std::deque<T>::iterator i = myQueue.begin(); i != myQueue.end(); ++i)
        if (pred(*i))
            theItem = *i;
            myQueue.erase(i);
            myQNotFull.signal();
            return true;
    return false;
struct fifthBitSet : public Predicate<hrtime_t *>
    bool operator()(hrtime_t * const &i) const { return (bool) ((*i) & (0x1L << 4)); }
class StressTest
public:
    StressTest(int consumers, int producers);
    ~StressTest();
    void start();
    void stop();
    void sleep(int seconds) { timer_.sleep(seconds * 1000); }
private:
    void consume();
    void produce();
    static void * consumer(void *arg);
    static void * producer(void *arg);
    static void joinThread(thread_t tid);
    Timer         timer_;
    PCQueue<hrtime_t*> queue_;
    vector<thread_t> consumers_;
    vector<thread_t> producers_;
StressTest::StressTest(int c, int p) : queue_(501), consumers_(c, 0L), producers_(p, 0L)
StressTest::~StressTest()
    hrtime_t *val = NULL;
    while (queue_.tryPop(val, 0))
        delete val;
void
StressTest::joinThread(thread_t tid)
    void * status;
    int rc = thr_join(tid,
                       NULL,
                       &status);
    if (rc != 0)
        char buf[80];
        snprintf(buf, sizeof(buf), "thr_join: unexpected rc: %d", rc);
        throw std::logic_error(buf);
void
StressTest::start()
    for (int i = 0; i < consumers_.size(); ++i)
        thread_t tid = 0L;
        thr_create(NULL, NULL, &consumer, this, NULL, &tid);
        consumers_ = tid;
for (int i = 0; i < producers_.size(); ++i)
thread_t tid = 0L;
thr_create(NULL, NULL, &producer, this, NULL, &tid);
producers_[i] = tid;
void
StressTest::stop()
timer_.cancel();
for (int i = 0; i < consumers_.size(); ++i)
queue_.push(NULL);
for_each(producers_.begin(), producers_.end(), joinThread);
for_each(consumers_.begin(), consumers_.end(), joinThread);
void *
StressTest::consumer(void *arg)
StressTest * test = reinterpret_cast<StressTest *>(arg);
test->consume();
return NULL;
void *
StressTest::producer(void *arg)
StressTest * test = reinterpret_cast<StressTest *>(arg);
test->produce();
return NULL;
void
StressTest::consume()
while (! timer_.isCancelled())
hrtime_t *ptime = queue_.pop();
while (ptime != NULL)
hrtime_t now = ::gethrtime();
if((now - *ptime) > 1000000000)
ostringstream os;
os << "Too old request: " << ((double)(now - *ptime)) / 1.0e9 << endl;
cerr << os.str() << flush;
delete ptime;
ptime = queue_.pop();
void
StressTest::produce()
while (! timer_.isCancelled())
hrtime_t *pnow = new hrtime_t;
*pnow = ::gethrtime();
bool qIsFull = ! queue_.tryPush(pnow);
while (qIsFull)
hrtime_t *pToRemove = NULL;
if (queue_.purge(fifthBitSet(), pToRemove) == false)
ostringstream os;
os << "Queue full, failed to make room, rejected call:" << *pnow << endl;
cerr << os.str() << flush;
delete pnow;
return;
if (pToRemove)
ostringstream os;
os << "Queue full, removed 1 item: " << *pToRemove << endl;
cerr << os.str() << flush;
delete pToRemove;
qIsFull = ! queue_.tryPush(pnow);
int
main(const int argc, char *argv[])
StressTest test(atoi(argv[1]), atoi(argv[2]));
test.start();
test.sleep(atoi(argv[3]));
test.stop();
Message was edited by:
anderso
Forgot to include the libumem log:
%>env | fgrep UMEM
UMEM_DEBUG=default,verbose
UMEM_LOGGING=transaction,contents,fail
%>(setenv LD_PRELOAD /usr/lib/64/libumem.so ; ./a.out 8 8 400)
umem allocator: redzone violation: write past end of buffer
buffer=1007c3aa0 bufctl=1007c81f0 cache: umem_alloc_48
previous transaction on buffer 1007c3aa0:
thread=d time=T-0.000430640 slab=100799e10 cache: umem_alloc_48
libumem.so.1'?? (0xffffffff7f216278)
libumem.so.1'?? (0xffffffff7f2166d0)
libumem.so.1'?? (0xffffffff7f2130ec)
libCrun.so.1'?? (0xffffffff7ec08810)
a.out'?? (0x100006df4)
a.out'?? (0x1000046ec)
a.out'?? (0x100003c04)
libc.so.1'?? (0xffffffff7e7cd2f8)
umem: heap corruption detected
stack trace:
libumem.so.1'?? (0xffffffff7f21471c)
libumem.so.1'?? (0xffffffff7f213574)
libCrun.so.1'?? (0xffffffff7ec0786c)
a.out'?? (0x100006e70)
a.out'?? (0x1000046ec)
a.out'?? (0x100003c04)
libc.so.1'?? (0xffffffff7e7cd2f8)
Abort (core dumped)
%>mdb core
> ::umem_verify
Cache Name Addr Cache Integrity
umem_magazine_1 100720028 clean
umem_magazine_3 100722028 clean
umem_magazine_7 100724028 clean
umem_magazine_15 100728028 clean
umem_magazine_31 10072a028 clean
umem_magazine_47 10072c028 clean
umem_magazine_63 100730028 clean
umem_magazine_95 100732028 clean
umem_magazine_143 100734028 clean
umem_slab_cache 100738028 clean
umem_bufctl_cache 10073a028 clean
umem_bufctl_audit_cache 10073c028 clean
umem_alloc_8 100742028 clean
umem_alloc_16 100748028 clean
umem_alloc_32 10074a028 clean
umem_alloc_48 10074c028 1 corrupt buffer
umem_alloc_64 100750028 clean
10074c028::umem_verifySummary for cache 'umem_alloc_48'
buffer 1007c3aa0 (allocated) has a corrupt redzone size encoding

This issue has been filed as bug 6514832, and will be visible at bugs.sun.com in a day or two.

[svn:fx-trunk] 11488: Resubmitting binary distribution of xercesPatch. jar from the third party module in the SDK and compiled it with Sun JDK 1.4 .2_12.

Revision: 11488
Author:   [email protected]
Date:     2009-11-05 17:10:10 -0800 (Thu, 05 Nov 2009)
Log Message:
Resubmitting binary distribution of xercesPatch.jar from the third party module in the SDK and compiled it with Sun JDK 1.4.2_12.
QE notes: N/A
Doc notes: N/A
Bugs:
SDK-16818 - Must open-source the code for xercesPatch.jar.
Reviewer: Discussed with Gordon
Tests run: Checkintests
Is noteworthy for integration: No
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-16818
Modified Paths:
    flex/sdk/trunk/lib/xercesPatch.jar
    flex/sdk/trunk/modules/thirdparty/xerces-patch/build.xml

Did you try this:
http://forum.java.sun.com/thread.jsp?thread=434718&forum=60&message=1964421

SS9 CC5.6 compiler bug - algorithm count confused with struct member

Found some code that fails to compile in CC 5.6
CC: Sun C++ 5.6 2004/07/15
#include <algorithm>
using namespace std;
struct A {
int count;
struct B
struct A *a;
int main(int argc, char **argv)
struct B *b = 0;
// This line fails to build, any other operator is ok
if ( b->a->count < 50 )
return (1);
}Fails with error :
"c56_algorithm_bug.cpp", line 21: Error: Unexpected ")" -- Check for matching parenthesis.
"c56_algorithm_bug.cpp", line 22: Error: "," expected instead of "{".
"c56_algorithm_bug.cpp", line 22: Error: Illegal value for template parameter.
"c56_algorithm_bug.cpp", line 22: Error: ")" expected instead of "{".
4 Error(s) detected.The compiler is getting confused with the use of the count struct member vs the count algorithm. Changing the < to a > fixes the problem.
Using CC5.3 works fine as well as all other compilers we use (gcc 3.4, mipspro 7.4, VC 7.1)
Anyone seen this ?
- mark

This bug has been fixed in the C++ 5.6 compiler. I'm not sure if the fix is in the first patch which is about to be released. If not, the fix definitely will be in the next patch.
The workaround is not to use
using namespace std;That using-declaration is a pretty big hammer, and often results in conflicts with user code, compiler bugs aside.

Ridiculous bug in oracle jdeveloper compiler ojc with jdk1.4

With simple class:
public class Test
public Test()
public String toString()
return null;
public static void main(String[] args) throws Exception
Test test = new Test();
System.out.println("ooo" + test);
After compile it with ojc (ojc Test.java) and run it with jdk 1.4.1_01 (java Test), it throws
java.lang.NullPointerException
at java.lang.String.concat(String.java:1541)
But it works ok if compile it with standard java compiler(javac).

Hi,
Thanks for reporting this. It's a bug. I've logged it as 2809860, and you can track this on metalink.oracle.com.
Brian
JDev Team

[svn] 3246: Fix fasttrack bug SDK-16910 - Simple List populated with strings throws RTE .

Revision: 3246
Author: [email protected]
Date: 2008-09-17 15:31:25 -0700 (Wed, 17 Sep 2008)
Log Message:
Fix fasttrack bug SDK-16910 - Simple List populated with strings throws RTE. This is fallout from the Group/DataGroup split. DefaultItemRenderer now uses a TextBox instead of a Group to show the list data.
QE: Any List tests that depended on the default item renderer to support anything other than text must be updated.
Bugs: SDK-16910
Ticket Links:
http://bugs.adobe.com/jira/browse/SDK-16910
http://bugs.adobe.com/jira/browse/SDK-16910
Modified Paths:
flex/sdk/trunk/frameworks/projects/flex4/src/flex/skin/DefaultItemRenderer.mxml

BTW, I do not experience the bug you had mentioned at
http://www.cs.rit.edu/~cxb0025/flex/TreeControlBugs.html
Can submit a video of my actions recorded

Optimization bug with C++ inlining

Hi,
While evaluating Sun Studio 11 I have identified an optimization bug with C++ inlining.
The bug can easily be reproduced with the small program below. The program produces
wrong results with -xO2, because an inline access function always returns the value 0.0
instead of the value given on the commandline:
djerba{ru}16 : CC -o polybug polybug.cc
djerba{ru}17 : ./polybug 1.0
coeff(0): 1.000000
djerba{ru}18 : CC -o polybug -xO2 polybug.cc
djerba{ru}19 : ./polybug 1.0
coeff(0): 0.000000            <<<<<<<<<< wrong, should be 1.000000This occurs only with optimization level O2; levels below or above O2 don't
exhibit the bug.
Compiler version is
Sun C++ 5.8 Patch 121017-01 2005/12/11
on Solaris 8 / Sparc.
I include a preliminary analysis at the end.
Best Regards
Dieter R.
-------------------- polybug.cc -------------------------
// note: this may look strange, but this is a heavily stripped down
// version of actual working application code...
#include <stdio.h>
#include <stdlib.h>
class Poly {
public:
    // constructor initializes number of valid coefficients to zero:
    Poly() { numvalid = 0; };
    ~Poly() {};
    // returns coefficient with index j, if valid. Otherwise returns 0.0:
    double coeff(int j) {
     if (j < numvalid) {
         return coefficients[j];
     } else {
         return 0.0;
   // copies contents of this Object to other Poly:
    void getPoly(Poly& q) { q = *this; };
    // data members:
    // valid coefficients: 0 ... (numvalid - 1)
    double coefficients[6];
    int numvalid;
void troublefunc(Poly* pC) {
    // copies Poly-Object to local Poly, extracts coefficient
    // with index 0 and prints it. Should be the value given
    // on commandline.
    // Poly constructor, getPoly and coeff are all inline!
    if (pC) {
     Poly pol;
     pC->getPoly(pol);
     printf("coeff(0): %f\n",pol.coeff(0));
int main(int argc,char* argv[]) {
    double d = atof(argv[1]);
    // creates Poly object and fills coefficient with index
    // 0 with the value given on commandline
    Poly* pC = new Poly;
    pC->coefficients[0] = d;
    pC->numvalid = 1;
    troublefunc(pC);
    return 0;
The disassembly fragment below shows that the access function coeff(0), instead
of retrieving coefficient[0] simply returns the fixed value 0.0 (presumably because the
optimizer "thinks" numvalid holds still the value 0 from the constructor and that therefore
the comparison "if (i < numvalid)" can be omitted).
Note: disassembly created from code compiled with -features=no%except for simplicity!
00010e68 <___const_seg_900000102>:
        ...     holds the value 0.0
00010e80 <__1cLtroublefunc6FpnEPoly__v_>:
   10e80:       90 90 00 08     orcc %g0, %o0, %o0      if (pC) {
   10e84:       02 40 00 14     be,pn   %icc, 10ed4
   10e88:       9c 03 bf 50     add %sp, -176, %sp
                                                   local Poly object at %sp + 120
                                                         numvalid at %sp + 0xa8 (168)
   10e8c:       c0 23 a0 a8     clr [ %sp + 0xa8 ]      Poly() { numvalid = 0; };
                                                         pC->getPoly(pol):
                                                         loop copies *pC to local Poly object
   10e90:       9a 03 a0 80     add %sp, 0x80, %o5
   10e94:       96 10 20 30     mov 0x30, %o3
   10e98:       d8 5a 00 0b     ldx [ %o0 + %o3 ], %o4
   10e9c:       96 a2 e0 08     subcc %o3, 8, %o3
   10ea0:       16 4f ff fe     bge %icc, 10e98
   10ea4:       d8 73 40 0b     stx %o4, [ %o5 + %o3 ]
                                                         pol.coeff(0):
                                                         load double value 0.0 at
                                                         ___const_seg_900000102 in %f0
                                                         (and address of format string in %o0)
   10ea8:       1b 00 00 43     sethi %hi(0x10c00), %o5
   10eac:       15 00 00 44     sethi %hi(0x11000), %o2
   10eb0:       c1 1b 62 68     ldd [ %o5 + 0x268 ], %f0
   10eb4:       90 02 a0 ac     add %o2, 0xac, %o0
   10eb8:       82 10 00 0f     mov %o7, %g1
                                                         store 0.0 in %f0 to stack and load it
                                                         from there to %o1/%o2
   10ebc:       c1 3b a0 60     std %f0, [ %sp + 0x60 ]
   10ec0:       d2 03 a0 60     ld [ %sp + 0x60 ], %o1
   10ec4:       d4 03 a0 64     ld [ %sp + 0x64 ], %o2
   10ec8:       9c 03 a0 b0     add %sp, 0xb0, %sp
                                                         call printf
   10ecc:       40 00 40 92     call 21114 <_PROCEDURE_LINKAGE_TABLE_+0x54>
   10ed0:       9e 10 00 01     mov %g1, %o7
   10ed4:       81 c3 e0 08     retl
   10ed8:       9c 03 a0 b0     add %sp, 0xb0, %sp
Hmmm... This seems to stress this formatting tags thing to its limits...

Thanks for confirming this.
No, this happens neither in an Open Source package nor in an important product. This is an internal product, which is continuously developed with Sun Tools since 1992 (with incidents like this one being very rare).
I am a bit concerned with this bug though, because it might indicate a weakness in the area of C++ inlining (after all, the compiler fails to correctly aggregate a sequence of three fairly simple inline functions, something which is quite common in our application). If, on the other hand, this is a singular failure caused by unique circumstances which we have hit by sheer (un)luck, it is always possible to work around this: explicitly defining a assignment operator instead of relying on the compiler-generated one is sufficient to make the bug go away.

Compiler error with default arguments and static template function

Hi
The following does not compile with visual studio 2010 sp1, and compiles with gcc.
#include <string>
class A
public:
template<class T>
static T& Get(const std::wstring&);
class B
public:
void f(
double d,
double c =A::Get<double>(L"test"));
int main()
B b;
b.f(5);
It gives me the following error
error C2783: 'T & A::Get(const wchar_t *)' : could not deduce template argument for 'T'
If I change Get to be global function and not static function of A, it compiles.

It seems to be a compiler bug. It fails in VS2012, but compiles in VS2013.
For completion sake, the problem exists if A is a namespace containing Get. But not if Get is global.
The only solutions I can see are try to workaround the problem (make Get global) or upgrade to a newer version of VS.

[svn:fx-trunk] 11926: Fix 3. 0 compatiblity-version bug with generated styles.

Revision: 11926
Revision: 11926
Author:   [email protected]
Date:     2009-11-18 04:46:03 -0800 (Wed, 18 Nov 2009)
Log Message:
Fix 3.0 compatiblity-version bug with generated styles.
src/java/flex2/compiler/common/CompilerConfiguration.java
   Turn ?\226?\128?\147isloate-styles off in 3.0 compatibility mode. This flag also turns on the hidden option ?\226?\128?\147allow-duplicate-default-style-declarations which is what fixes the bug.
src/java/flex2/compiler/css/StyleDef.vm
   Changed a tab to spaces.
QE notes: None.
Doc notes: None.
Bugs: SDK-24259
Reviewer: Peter
Tests run: checkintests
Is noteworthy for integration: no
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-24259
Modified Paths:
    flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/common/CompilerConfiguration.java
    flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/css/StyleDef.vm

FYI - This regression has been filed here: http://bugs.adobe.com/jira/browse/SDK-31989

[svn:fx-trunk] 11707: Fix incremental compilation problem with styles.

Revision: 11707
Author:   [email protected]
Date:     2009-11-12 10:52:49 -0800 (Thu, 12 Nov 2009)
Log Message:
Fix incremental compilation problem with styles.
QE notes: None.
Doc notes: None.
Bugs: SDK-24173
Reviewer: Paul
Tests run: checkintests
Is noteworthy for integration: No.
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-24173
Modified Paths:
    flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/css/StylesContainer.java

You have used elements like header, footer, footer1 and nav without using the correct DOCTYPE declaration. Replace the first line of your code with
<!doctype html>
Also have a look here for other problems http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fhome.surewest.net%2Fstorytales%2F test%2Fforposting.html
After the above has been fixed, please come back here to fix the remaining problem(s)
Gramps

Possible bug with c interop in fortran

A colleague and I are writing some c interop examples for a book and have come across a possibe bug.
We are testing passing 2 d arrrays (c99 vla) between fortran, c and c++.
Fortran main program calling c function works.
C main program calling Fortran subroutine works.
C++ calling fortran subroutine fails.
here is the fortran soubroutine
subroutine reciprocal(nr,nc,x,y) bind(c,name='reciprocal')
use iso_c_binding
implicit none
integer (c_int) , value :: nr
integer (c_int) , value :: nc
real (c_float) , dimension(1:nr,1:nc) , intent(in ) :: x
real (c_float) , dimension(1:nr,1:nc) , intent(out) :: y
y=1.0/x
end subroutine reciprocal
we compile this with
sunf90 -c ch3110.f90 -o ch3110_f.o
we then try compiling the following with
sunCC ch3110.cxx ch3110_f.o
#include <iostream>
using namespace std;
extern "C" void reciprocal(int nr,int nc,float x[nr][nc],float y[nr][nc]);
int main()
const int nr=2;
const int nc=5;
float x[nr][nc];
float y[nr][nc];
float t[]={1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0};
int r;
int c;
int i=0;
for (r=0;r<nr;r++)
    for (c=0;c<nc;c++)
      x[r][c]=t[i];
      i++;
cout << " C++ passing a 2d array to Fortran " << endl;
for (r=0;r<nr;r++)
    for (c=0;c<nc;c++)
      cout << x[r][c] << " ";
    cout << endl;
reciprocal(nr,nc,x,y);
for (r=0;r<nr;r++)
    for (c=0;c<nc;c++)
      cout << " 1 / " << x[r][c] << " = " << y[r][c] << endl;
return(0);
and get the following error message
ian@linux-9624:~/document/fortran/third_edition/examples> sunf90 -c ch3110.f90 -o ch3110_f.o
ian@linux-9624:~/document/fortran/third_edition/examples> sunCC ch3110.cxx ch3110_f.o
"ch3110.cxx", line 5: Error: An integer constant expression is required within the array subscript operator.
"ch3110.cxx", line 5: Error: An integer constant expression is required within the array subscript operator.
"ch3110.cxx", line 5: Error: An integer constant expression is required within the array subscript operator.
"ch3110.cxx", line 5: Error: An integer constant expression is required within the array subscript operator.
"ch3110.cxx", line 36: Error: Formal argument x of type float(*)[1] in call to reciprocal(int, int, float(*)[1], float(*)[1]) is being passed float[2][5].
"ch3110.cxx", line 36: Error: Formal argument y of type float(*)[1] in call to reciprocal(int, int, float(*)[1], float(*)[1]) is being passed float[2][5].
6 Error(s) detected.
ian@linux-9624:~/document/fortran/third_edition/examples>
We get the same (or similar) error messages from
g++ and gfortran 4.8.x
g++ and gfortran 4.10.x
    we failed a bug report with the gnu team
    and it is reported as a duplicate of an existing bug.
microsoft C++ and Intel fortran
    microsoft do not support C99 vla.
The only combination that we have found that
works is with the Intel beta versions of their
fortran and C++ compilers.
Any thoughts?
Ian Chivers

It appears to be a question of standards conformance and what standards :-(
The gfortran and Intel C++ compilers are tracking the c99
standard.Microsoft have stated that they will not be supporting c99 in
their C++ compiler.
I have found a statement that C++14 will support c99 vla.
Jane and I have a
c99 and Fortran 90 combination where the above syntax works.
source code below.
c source file
=========
+++++
#include <stdio.h>
void reciprocal(int nr,int nc,float x[nr][nc],float y[nr][nc]);
int main()
const int nr=2;
const int nc=5;
float x[nr][nc];
float y[nr][nc];
float t[]={1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0};
int r;
int c;
int i=0;
for (r=0;r<nr;r++)
    for (c=0;c<nc;c++)
      x[r][c]=t[i];
      i++;
printf(" C passing a 2d array to Fortran\n");
for (r=0;r<nr;r++)
    for (c=0;c<nc;c++)
      printf(" %f " , x[r][c]);
    printf("\n");
reciprocal(nr,nc,x,y);
for (r=0;r<nr;r++)
    for (c=0;c<nc;c++)
      printf(" 1 / %f = %f \n" , x[r][c],y[r][c]);
    printf("\n");
return(0);
+++++
fortran source file
=============
subroutine reciprocal(nr,nc,x,y) bind(c,name='reciprocal')
use iso_c_binding
implicit none
integer (c_int) , value :: nr
integer (c_int) , value :: nc
real (c_float) , dimension(1:nr,1:nc) , intent(in ) :: x
real (c_float) , dimension(1:nr,1:nc) , intent(out) :: y
y=1.0/x
end subroutine reciprocal
+++++
this combination WORKS
with the sun compiler suite.
Finally you mentiion
+++++
Finally, when linking Fortran and C++ code, you must use the C++ compiler (CC) to do the link step, and you must use the option -xlang=f90 to get all the libraries linked in the right order:
CC ch3110.cxx ch3110_f.o -xlang=f90
Refer to the xlang option in the C++ Users Guide for more information.
++++
jane and i did not need to do the above using c interop with the other mixed language examples
we have written and have working.
we have a scalar parameter passing example
fortran calling c
c calling fortran
c++ calling fortran
that works with the 12.4 beta suite.
we have a 1 d array example
fortran calling c
c calling fortran
c++ calling fortran
working with the 12.4 beta suite.
I was under the impression that
sunCC
pointed to the sun C++ compiler.
so from your reply I assume that our example will not work with the current
sun/oracle C++ compiler, but may work if sun track the C++14
standard.
here is the source code for our 1d fortran C++ combo
c++
===
#include <iostream>
using namespace std;
extern "C" float summation(float *,int );
int main()
const int n=10;
float *x;
int i;
x = new float[n];
for (i=0;i<n;i++)
    x[i]=1.0f;
cout << " C++ passing an array to Fortran " << endl;
cout << " Sum is " << summation(x,n) << endl;
return(0);
Fortran
=====
function summation(x,n) bind(c,name='summation')
use iso_c_binding
implicit none
integer (c_int) , value :: n
real (c_float), dimension(1:n) , intent(in) :: x
real (c_float) :: summation
integer :: i
summation=sum(x(1:n))
end function summation
this fortran C++ combo works.
Notes
====
From the reply we got from the gnu team they wil be implementing
the functionality at some point.
Intel already does in their beta.
Microsoft will not as they are not tracking
c99.
Thanks for you time.

SDK 3.0: Compiler bug with std::deque?

Similar Messages

Maybe you are looking for