(OK) cBPM(段错误(吐核))—((EndWorkflowEvent*)evt)->getProcessID()—getenv 返NULL

 

 

 

★★★★★上面的问题——解决了：

--------> /opt/cBPM/criteria-lin/src/Criteria/Criteria.WorkflowEngine/events/WorkflowListener.cpp

注释掉两行：（取消注释，会出现上面问题，有待解决）

 

    else if ( evt->getName() == "EndWorkflowEvent" )

{

        CM_TRACE_CODEPATH( "Event Received:[EndWorkflowEvent]")

        //processID = ((EndWorkflowEvent*)evt)->getProcessID();

        //sEvent = "COMPLETED";

}

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

★★★★★ ( getenv  返回值为 NULL )

--------> /opt/cBPM/criteria-lin/src/Criteria/Criteria.WorkflowEngine/engine/Workflow.cpp

CM_TRACE_CODEPATH( "Deleting TaskAction Object.")

delete taskAction; 设置断点

 

 

--------> /opt/cBPM/criteria-lin/src/Criteria/Criteria.WorkflowEngine/events/WorkflowListener.cpp

        processID = ((EndWorkflowEvent*)evt)->getProcessID(); 设置断点

调用

--------> /opt/cBPM/criteria-lin/src/Criteria/Criteria.WorkflowEngine/events/BaseWorkflowEvent.cpp

    return _WF->getProcess()->getProcessId();  设置断点

调用

--------> /opt/cBPM/criteria-lin/src/Criteria/Criteria.WorkflowEngine/engine/Workflow.cpp

WorkflowProcesses::WorkflowProcess* Workflow::getProcess() 设置断点

{

    return process;

}

--------> /opt/cBPM/criteria-lin/include/WorkflowEngine/Workflow.h

WorkflowProcesses::WorkflowProcess*    process;

 

★★★★★上面的问题——终于解决了：( getenv  返回值为 NULL )（Program works from commandline, but not from codeblocks）

style="font-family:Calibri;font-size:12.0000pt;">

 

 

resander: 
I inserted the following three calls at the start of connectSrv routine (see a previous post on this thread):

char * odbcini = getenv ( "ODBCINI" ) ;
char * oraclehome = getenv ( "ORACLE_HOME" ) ;
char * ldlibrarypath = getenv ( "LD_LIBRARY_PATH" ) ;
 
char * getenv (const char *name)
returns a string that is the value of the environment variable name. 
If the environment variable name is not defined, the value is a null pointer. 


Starting codeblocks from Application menu

The odbcini and oraclehome variables are NULL after the getenv calls. This means they are not available for my program, which fails finding the ODBC driver and other library dependencies. The ldlibrarypath variable is .:, which is wrong.

Starting codeblocks from my HOME /home/ken and commandline as /usr/bin/codeblocks
Works.

Wikipedia says this about environment:

'In all Unix and Unix-like systems, each process has its own private set of environment variables. By default, when a process is created it inherits a duplicate environment of its parent process, except for explicit changes made by the parent when it creates the child. At API level, these changes must be done between fork and exec.'

When I start codeblocks from the commandline my environment is inherited by codeblocks. Then if codeblocks starts my-prog by exec/fork the environment would be passed on again, which is what my-prog needs.

There is a predefined program variable extern char ** environ; which is an array of property strings in the environment. When starting codeblocks from the Application menu I put these to the screen with printf and could see the environment was different from mine. 

- there are fewer properties, especially the important ODBCINI, 
  ORACLE_HOME are missing

- LD_LIBRARY_PATH is .: which is different from my ldlibpath

- PWD is set to /home/ken/Projects/lsken2      my PWD is /home/ken

- HOME is /home/ken for both (can be used to chdir $HOME before starting
  codeblocks from menu)

 

 

-------------------------

 

-------------------------

 

++++++++++++++++++++++++++++++++++++++++++++++++++

resander:
I inserted the following three calls at the start of connectSrv routine (see a previous post on this thread):

char * odbcini = getenv ( "ODBCINI" ) ;
char * oraclehome = getenv ( "ORACLE_HOME" ) ;
char * ldlibrarypath = getenv ( "LD_LIBRARY_PATH" ) ;
 
char * getenv (const char *name)
returns a string that is the value of the environment variable name.
If the environment variable name is not defined, the value is a null pointer.


Starting codeblocks from Application menu

The odbcini and oraclehome variables are NULL after the getenv calls. This means they are not available for my program, which fails finding the ODBC driver and other library dependencies. The ldlibrarypath variable is .:, which is wrong.


Starting codeblocks from my HOME /home/ken and commandline as /usr/bin/codeblocks

Works.


Wikipedia says this about environment:

'In all Unix and Unix-like systems, each process has its own private set of environment variables. By default, when a process is created it inherits a duplicate environment of its parent process, except for explicit changes made by the parent when it creates the child. At API level, these changes must be done between fork and exec.'

When I start codeblocks from the commandline my environment is inherited by codeblocks. Then if codeblocks starts my-prog by exec/fork the environment would be passed on again, which is what my-prog needs.

There is a predefined program variable extern char ** environ; which is an array of property strings in the environment. When starting codeblocks from the Application menu I put these to the screen with printf and could see the environment was different from mine.

- there are fewer properties, especially the important ODBCINI,
  ORACLE_HOME are missing

- LD_LIBRARY_PATH is .: which is different from my ldlibpath

- PWD is set to /home/ken/Projects/lsken2      my PWD is /home/ken

- HOME is /home/ken for both (can be used to chdir $HOME before starting
  codeblocks from menu)