Hi John.. Im trying to build OpenCORE outside of Android(Ubuntu-9.04)
I followed the instructions given in quich_start.txt.. I want to knwo some details regarding this. 1) Is thr any memory constraints related to this build? 2) How much time it will take to build ? Because after giving "make -j" command after some time my system is got hanged.. i think build process is going on internally, i dont think so?? U have good idea on this if im not wrong because u already did it right?? Pls help me if im going wrong... any help would greatly appreciated. On Nov 12, 1:56 pm, John Lee <[email protected]> wrote: > Hi Ravi, > > The same problem happens in several places. I also have to fix > > H223LogicalChannel::~H223LogicalChannel() > PVCommsIONodePort::~PVCommsIONodePort() > > I have tried a similar method to fix this before, but > pv2way_omx_engine_test will hang after some more tests, and I'm not > sure if it's related. Will start tracing that. Here is the results > after I set iPortActivityHandler to NULL in all 3 places: > > [output] > > Start avtest, proxy 1,Audio SrcFormat:X-AMR-IF2 Audio SinkFormat:X-AMR-IF2 > Video SourceFormat:X-YUV-420 Video SinkFormat:video/MP4V-ES > Indication with logical channel #6 Audio outgoing Track > Indication with logical channel #7 Video outgoing Track > Indication with logical channel #65542 Audio incoming Track > Indication with logical channel #65543 Video incoming Track > Start avtest, proxy 1,Audio SrcFormat:X-AMR-IF2 Audio SinkFormat:X-AMR-IF2 > Video SourceFormat:video/MP4V-ES Video SinkFormat:X-YUV-420 > Indication with logical channel #6 Audio outgoing Track > Indication with logical channel #7 Video outgoing Track > Indication with logical channel #65542 Audio incoming Track > > [hang, ctrl-c, backtrace] > > (gdb) bt > #0 0xf7fdf430 in __kernel_vsyscall () > #1 0xf76501f5 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib32/libpthread.so.0 > #2 0xf7b6637b in OsclSemaphore::Wait (this=0x807c278) > at > /home/john/scm/mydroid/external/opencore/oscl/oscl/osclproc/src/oscl_semaphore.cpp:116 > #3 0xf7b647e6 in OsclReadyQ::WaitAndPopTop (this=0x807c218) > at > /home/john/scm/mydroid/external/opencore/oscl/oscl/osclproc/src/oscl_scheduler_readyq.cpp:123 > #4 0xf7b60f99 in OsclExecSchedulerCommonBase::WaitForReadyAO (this=0x807c168) > at > /home/john/scm/mydroid/external/opencore/oscl/oscl/osclproc/src/oscl_scheduler.cpp:1380 > #5 0xf7b60d97 in OsclExecSchedulerCommonBase::BlockingLoopL (this=0x807c168) > at > /home/john/scm/mydroid/external/opencore/oscl/oscl/osclproc/src/oscl_scheduler.cpp:1290 > #6 0xf7b5fcfe in OsclExecSchedulerCommonBase::StartScheduler > (this=0x807c168, aSignal=0x0) > at > /home/john/scm/mydroid/external/opencore/oscl/oscl/osclproc/src/oscl_scheduler.cpp:797 > #7 0x0805dc9f in av_test::test (this=0x819a1e0) > at > /home/john/scm/mydroid/external/opencore/engines/2way/test/src/av_test.cpp:51 > #8 0x08062a47 in test_case::run_test (this=0x819a1e0) > at > /home/john/scm/mydroid/external/opencore/oscl/unit_test/src/test_case.cpp:57 > #9 0x080629c6 in test_case::run_subtests (this=0xffffcaf4) > at > /home/john/scm/mydroid/external/opencore/oscl/unit_test/src/test_case.cpp:44 > #10 0x08062a35 in test_case::run_test (this=0xffffcaf4) > at > /home/john/scm/mydroid/external/opencore/oscl/unit_test/src/test_case.cpp:55 > #11 0x080556da in start_test () at > /home/john/scm/mydroid/external/opencore/engines/2way/test/src/test_engine.cpp:852 > #12 0x08055602 in test_wrapper () at > /home/john/scm/mydroid/external/opencore/engines/2way/test/src/test_engine.cpp:761 > #13 0x08055659 in local_main (filehandle=0xf761b4c0, command_line=0xffffcc10) > at > /home/john/scm/mydroid/external/opencore/engines/2way/test/src/test_engine.cpp:790 > #14 0x08064bd0 in main (argc=1, argv=0xffffccf4) > at > /home/john/scm/mydroid/external/opencore/oscl/unit_test/src/unit_test_main.cpp:70 > > Regards, > John > > On Wed, Nov 11, 2009 at 06:52:09AM -0800, RaviY wrote: > > We found a similar problem. Please try to set "iPortActivityHandler to > > NULL" in the destructor of "H223LowerLayer". > > > -Ravi > > > On Nov 11, 8:12�am, John Lee <[email protected]> wrote: > > > Hi list, > > > > I've been trying to compile and run opencore on native PC following > > > the instructions in quick_start.txt . The reason I want to do this is > > > that it's supposed to be easier to work on host pc since what I want > > > to do is not hardware dependent, but so far it doesn't seem to be the > > > case. After 8 bug fix commits I managed to finish the compilation, but > > > other problem follows. �Here is the problem description: > > > > Since H223LowerLayer is both PvmfPortBaseImpl and > > > PVMFPortActivityHandler, it sends itself to the constructor of > > > PvmfPortBaseImpl to act as its iPortActivityHandler. During the > > > destruction of PvmfPortBaseImpl, > > > iPortActivityHandler->HandlePortActivity will be called. �The problem > > > is, the real implementation of HandlePortActivity lies inside > > > H223LowerLayer, and the order of destruction is: > > > > ~H223LowerLayer > > > ~PvmfPortBaseImpl > > > � iPortActivityHandler->HandlePortActivity > > > > So when HandlePortActivity is actually invoked, > > > H223LowerLayer::HandlePortActivity() is already invalid, and the code > > > path falls to PVMFPortActivityHandler::HandlePortActivity, which is a > > > pure virtual function. This will cause a SIGABRT: > > > > pure virtual method called > > > terminate called without an active exception > > > > Program received signal SIGABRT, Aborted. > > > > (Backtrace enclosed.) > > > > p.s. Here is the snipped source code related to this issue: > > > > external/opencore/protocols/systems/3g-324m_pvterminal/h223/include/lowerlayer.h: > > > class H223LowerLayer : public PvmfPortBaseImpl, > > > � � � � public PVMFPortActivityHandler > > > > }; > > > > external/opencore/pvmi/pvmf/include/pvmf_port_base_impl.h: > > > class PvmfPortBaseImpl : public PVMFPortInterface > > > { > > > � � � � OSCL_IMPORT_REF PvmfPortBaseImpl(int32 aPortTag, > > > PVMFPortActivityHandler* aNode, const char*name = NULL); > > > > }; > > > > external/opencore/pvmi/pvmf/include/pvmf_port_interface.h: > > > class PVMFPortInterface > > > { > > > � � � � PVMFPortActivityHandler *iPortActivityHandler; > > > > }; > > > > external/opencore/pvmi/pvmf/include/pvmf_node_interface.h: > > > class PVMFPortActivityHandler > > > { > > > � � public: > > > � � � � virtual ~PVMFPortActivityHandler() {} > > > � � � � virtual void HandlePortActivity(const PVMFPortActivity &) > > > = 0; > > > > }; > > > > implementation: > > > > external/opencore/protocols/systems/3g-324m_pvterminal/h223/src/lowerlayer.cpp: > > > H223LowerLayer::H223LowerLayer(int32 aPortTag, TPVLoopbackMode > > > aLoopbackMode) > > > � � � � : � PvmfPortBaseImpl(aPortTag, this), > > > { > > > > } > > > > external/opencore/pvmi/pvmf/src/pvmf_port_base_impl.cpp: > > > OSCL_EXPORT_REF PvmfPortBaseImpl::PvmfPortBaseImpl(int32 aTag, > > > PVMFPortActivityHandler* aNode, const char*name) > > > � � � � : PVMFPortInterface(aNode), > > > { > > > > } > > > > OSCL_EXPORT_REF PvmfPortBaseImpl::~PvmfPortBaseImpl() > > > { > > > � � PortActivity(PVMF_PORT_ACTIVITY_DELETED); > > > > } > > > > OSCL_EXPORT_REF void PvmfPortBaseImpl::PortActivity(PVMFPortActivityType > > > aActivity) > > > { > > > � � if (iPortActivityHandler) > > > � � { > > > � � � � PVMFPortActivity activity(this, aActivity); > > > � � � � iPortActivityHandler->HandlePortActivity(activity); > > > � � } > > > > } > > > > �bt.txt > > > 4KViewDownload > > > -- > > unsubscribe: [email protected] > > website:http://groups.google.com/group/android-porting -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
