[ace-users] Page fault on VxWorks when activating a task

Alberto Salmerón Moreno salmeron at lcc.uma.es
Thu Jul 26 13:23:56 CDT 2007


Hi Johnny,

Regarding the comments about the configure script problems for Linux,
we will take a look at the generated configure parameters as well, and
see if we can find the offending one for the high resolution timers
:).

By the way, we've continued woking on our migration towards VxWorks
but we've found an unexpected problem: activating a task always
results in a page fault. Here is the PRF:

Thanks in advance

ACE VERSION: 5.5.8

HOST MACHINE and OPERATING SYSTEM: Intel Pentium D, Windows XP SP2 (WINSOCK 2)

TARGET MACHINE and OPERATING SYSTEM, if different from HOST: Pentium,
VxWorks 5.5.1

COMPILER NAME AND VERSION (AND PATCHLEVEL):  gcc 2.9-PentiumIII-010221,
GNU Make 3.80 (31may05: with gvk patches)

THE $ACE_ROOT/ace/config.h FILE:

#include "ace/config-vxworks5.x.h"

THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE:

include $(ACE_ROOT)/include/makeinclude/platform_vxworks5.5.x.GNU

CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
(used by MPC when you generate your own makefiles):

AREA/CLASS/EXAMPLE AFFECTED:

DOES THE PROBLEM AFFECT: COMPILATION, ACE fails to compile

SYNOPSIS:
Activating or spawning a thread results in a page fault.

DESCRIPTION:
We are trying to run some of the ACE tests for VxWorks 5.5, and in
everyone of them activating a task results in a page fault. We have
also done small test programs to isolate the problem and task
activation or thread spawning always yields a page fault.

We have also activated the ACE tracing support and we believe that the
trace on the activate method is never reached. For example, here is
the result for the simple test that can be found below (just
activating a new task):

(67108420) calling ACE_Task<ACE_SYNCH_USE>::ACE_Task in file
`C:/work/ACE_wrappers/ace/Task_T.cpp' on line 55
   (67108420) calling
ACE_Message_Queue<ACE_SYNCH_USE>::ACE_Message_Queue in file
`C:/work/ACE_wrappers/ace/Message_Queue_T.cpp' on line 930
      (67108420) calling ACE_Message_Queue<ACE_SYNCH_USE>::open in
file `C:/work/ACE_wrappers/ace/Message_Queue_T.cpp' on line 986
      (67108420) leaving ACE_Message_Queue<ACE_SYNCH_USE>::open
   (67108420) leaving ACE_Message_Queue<ACE_SYNCH_USE>::ACE_Message_Queue
(67108420) leaving ACE_Task<ACE_SYNCH_USE>::ACE_Task
(67108420) calling ACE_Task<ACE_SYNCH_USE>::~ACE_Task in file
`C:/work/ACE_wrappers/ace/Task_T.cpp' on line 70
   (671084
20) calling ACE_MesPage Faultsage_Queue
<ACE_SYNCH_USE>::~APage Dir Base   : 0x0CE_Message_Queue in3fd8000 file `C:/wor
k/ACE_wrappers/ace/Esp0 0xMessage_Queue0_T.cpp' on line 9403f542ec
 : 0x00386536   (67108420) leavi, 0xng
ACE_Message_Qf000ef6fueue<ACE_SYN,
0xCH_USE>::~ACE_Meffffffffssage_Queue
, 0x(67108420) leavi0ng ACE_Task<ACE_SYN3f551f4CH_USE>::~ACE
_Task
Esp0 0x03f542fc : 0x03f55348, 0x03f543c4, 0x00000000, 0x03f54418
Program Counter : 0x003c9716
Code Selector   : 0x00000008
Eflags Register : 0x00010286
Error Code      : 0x00000000
Page Fault Addr : 0xf000ef76
Task: 0x3f544e8 "t1"

REPEAT BY:

/* run_main.cpp *********
class MyTask : public ACE_Task<ACE_MT_SYNCH> {
	public:
		MyTask() {};
		int svc() {
			ACE_DEBUG((LM_TRACE, "MyTask::svc()\n"));
		}
};

int run_main(int argc, ACE_TCHAR *argv[]) {
	ACE_LOG_MSG->priority_mask(LM_TRACE, ACE_Log_Msg::PROCESS);
    MyTask task();
    if (task.activate(THR_NEW_LWP|THR_DETACHED|THR_INHERIT_SCHED) == -1) {
    	ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "task.activate()"), 1);
    }
    return 0;
}
***************************/


SAMPLE FIX/WORKAROUND:

On 7/24/07, Johnny Willemsen <jwillemsen at remedy.nl> wrote:
> Hi,
>
> > > Have you also tested with the traditional way of
> > compilation? My first
> > > question would be whether this is a code change or an
> > autoconf change you
> > > see. Be aware of the fact that 99% of the tests on the
> > scoreboard is using
> > > traditional way of compilation.
> >
> > Thanks for the quick response! Compiling the traditional work did
> > work. I would have never thought of that. Do you know what kind of
> > parameter can have an influence on timers that the 'configure' script
> > doesn't get right?
>
> The configure script does check a lot of defines, but it really isn't
> complete. A large amount of work has to be done to improve that support, but
> that will need funding. Probably something gets detected wrong and then in
> ACE_OS::gethrtime() the wrong code is triggered.
>
> Regards,
>
> Johnny Willemsen
> Remedy IT
> Postbus 101
> 2650 AC  Berkel en Rodenrijs
> The Netherlands
> www.theaceorb.nl / www.remedy.nl
>
> *** Integrated compile and test statistics see
> http://scoreboard.theaceorb.nl ***
> *** Commercial service and support for ACE/TAO/CIAO             ***
> *** See http://www.theaceorb.nl/en/support.html                 ***
>
>
>



More information about the Ace-users mailing list