Michael Haubenwallner | 13 Apr 11:01 2015

nsd (name service server) filename conflict with NameServerDaemon


as shown in https://bugs.gentoo.org/show_bug.cgi?id=544488 the file name of
MICO name service server "nsd" is in conflict with the "Name Service Daemon"
project http://www.nlnetlabs.nl/projects/nsd/

Question now is how to solve this conflict - the options I can see for now is:
*) Rename the Name Service Daemon project to something different.
*) Rename MICO "nsd" to "mico-nsd", plus optionally (build-time?)
   keep symlink "nsd -> mico-nsd" for backwards compatibility.

Using "nsd" for the "Name Service Daemon" project IMHO feels more natural than
for the "MICO name service server", where "mico-nsd" feels appropriate as well.



BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
hector rey | 15 Mar 15:49 2015

How to compile with MinGW?


      I want to use MICO with DevC++.  I think that it`s the same as MinGW, so I want to compile it in MinGW, but the INSTALL file says "Follow instructions for patching MinGW at  http://www.geocrawler.com/archives/3/6013/2002/1/100/7606374/ ".
      It seems than www.geocrawler.com in down.  Does anyone has a copy of this?



Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
alireza.azarnia | 23 Nov 02:34 2014

alireza.azarnia <at> gmail.com has indicated you're a friend. Accept?

Click here to discover alireza.azarnia <at> gmail.com's favorite websites!
alireza.azarnia <at> gmail.com wants to follow you
I would like to add you as a friend
-alireza.azarnia <at> gmail.com
Accept Decline
Following alireza.azarnia <at> gmail.com helps you discover great websites they recommend :)
Click here to unsubscribe from such emails from alireza.azarnia <at> gmail.com or all friends

P.O. BOX 70928, Sunnyvale, CA 94086
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
imcompo | 19 Nov 16:06 2014

idl compilation fail with VS2012


Here is my configuration with which I tried to compiled
the latest snapshot of 2014 name : mico-2014-02-13
(but I have also try with other packages)

- windows 7 with all fix and servicepack
- Visual Studio 2012

The compilation works well until the ide generator use :
I have an error in \mico-2014-02-13\orb\os-thread\pthreads.cc, line 496 
and idl crashed.

I do not think it comes from the pthread dll because I use the same
in other element of my framework.

Have you a solution ?

I need to compile with 2012 because all my framework developpement is 
compiled with
(C++) then if I use 2008 (I could), there will be mangling problem.

Thanks for answer.


Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
Raghu Jayan | 19 May 22:11 2014

Windows 64 bit build


Based on a post in this mailing list I tried to obtain the Win64 port
using darcs:

darcs get --set-scripts-executable http://mico.org/mico-darcs-repository mico

However, I get an error when I run it. I get the following message,

darcs failed:  Not a repository: http://mico.org/mico-darcs-repository

HINT: Do you have the right URI for the repository?

      If so, check with the repository owner to see if the following files
      are readable:

        1. _darcs/format    - might not exist; that's OK
        2. _darcs/inventory - should exist if #1 is missing
        3. _darcs/hashed_inventory - should exist if #2 is missing

Has anyone been able to successfully compile x64 windows version? I
would appreciate any pointers in this regard.

Thanks in advance,


"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
Schneider, Wolfgang | 9 Dec 17:40 2013

Calling MICO::IIOPProxy::kill_conn can trigger memory race conditions

Hello MICO developers,

in my scenario a MICO service is called from a client process and delegating
those calls as several parallel invocations to further CORBA services. If
one of those delegation services is shut down, the service in the middle
could crash because of multiple deletes on the same IIOPProxyInvokeRec
One of the delete candidates is the method IIOPProxy::del_invoke called in
IIOPProxy::abort_invoke itself. Another one is triggered as callback
function in CORBA::ORB::get_invoke_reply.

The following changes in MICO snapshot 2012 are my first try to fix the
problem (see the lines marked with // Wolfgang Schneider comments).  Up to
now I didn't test that very heavily. So I'm very interested if you see any
side effects of my fix which I didn't had in mind.

Thanks a lot for any help.


MICO::IIOPProxy::abort_invoke (CORBA::ORBMsgId id)
    // make invocation fail; notify orb ...
    if (MICO::Logger::IsLogged (MICO::Logger::IIOP)) {
	MICOMT::AutoDebugLock __lock;
	MICO::Logger::Stream (MICO::Logger::IIOP)
	    << "GIOP: invocation(" << id << ") aborted" << endl;

    IIOPProxyInvokeRec* inv_rec = pull_invoke(id);

	// Wolfgang Schneider, change 9.12.2013
	// Do not delete the id object in invoke callback action

    switch (_orb->request_type (id)) {
    case CORBA::RequestInvoke: {
	CORBA::Object_var obj = new CORBA::Object (new CORBA::IOR);
	CORBA::Request_var req =
	    new CORBA::Request (obj, "someop");
	LocalRequest orbreq (req);
	orbreq.set_out_args (
	_orb->answer_invoke (id, CORBA::InvokeSysEx,
			     CORBA::Object::_nil(), &orbreq, 0);
    case CORBA::RequestLocate:
	_orb->answer_locate (id, CORBA::LocateUnknown,
			     CORBA::Object::_nil(), 0);
    case CORBA::RequestBind:
	_orb->answer_bind (id, CORBA::LocateUnknown,

	assert (0);



CORBA::ORB::get_invoke_reply (ORBMsgId id, Object_out obj, ORBRequest *&r,
			      GIOP::AddressingDisposition &ad)
    ORBInvokeRec *rec = get_invoke (id);
    assert (rec);

	//Wolfgang Schneider, change 9.12.2013
	//The id object will be deleted by IIOPProxy::abort_invoke 
	bool invoke_aborting = id->active() == false;

    InvokeStatus state;
    Object_ptr o;
    CORBA::Boolean ret = rec->get_answer_invoke (state, o, r, ad);
    assert (ret);
    obj = Object::_duplicate (o);
	//Wolfgang Schneider, change 9.12.2013
	//The id object will be deleted by IIOPProxy::abort_invoke 
	//del_invoke ( rec->id() );
   	 if ( !invoke_aborting ) {
		del_invoke ( rec->id() );

    // XXX has to be changed for MT
    //_currentid = 0;
    if (!_currentid.empty()) {
    stack<CORBA::ORBInvokeRec*>* invs =
    if (invs != NULL && !invs->empty()) {
#endif // HAVE_THREADS
    return state;

Attachment (smime.p7s): application/pkcs7-signature, 8 KiB
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
Felipe Magno de Almeida | 4 Nov 12:33 2013

fwd_ior threading race and patch

Hello Karel,

We noticed a race with the fwd_ior member of Object when multiple
threads made calls concurrently. We've fixed it by moving the forward
object outside the reference and to the algorithms. The attached patch
has been working for over 1 year.

Any comments are appreciated,


Felipe Magno de Almeida
Attachment (forward_ior.patch): application/octet-stream, 20 KiB
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
Karel Gardas | 12 Oct 17:12 2013

Re: MICO cryptic problem

On 10/12/13 04:48 PM, andreis <at> eed.usv.ro wrote:
> Hi Karel
> Thank you kindly for the fast reply.
> CORBA::Object_var nsobj = orb->resolve_initial_references("NameService");
> // after this line, variable nsobj is not NULL.
> CosNaming::NamingContext_var nc=CosNaming::NamingContext::_narrow(nsobj);
> // after this line, nc is also not NULL but a CORBA::INV_POLICY exception
> //apears in the Visual Studio Output window. I must also mention that the
> //execution continues even after the exception is thrown, leading me to
> //think it is being caught somewhere in MICO code.

Do not be that confused about INV_POLICY being displayed in VS. IIRC it 
displays also caught policies. If you are curious what's happening in 
this case is that _narrow attempts to open IIOP connection to target 
object and as part of this code there is also a logic which tries to 
obtain ContextEstablishmentPolicy from the target object reference. By 
spec, if such policy is not associated with the target object 
Object::_get_policy should throw CORBA::INV_POLICY exception which is 
caught and code continues... See iop.cc, and seek for 
MICO::IIOPProxy::make_conn (CORBA::Object_ptr obj, CORBA::Boolean& 
timedout) if you are interested in seeing the code in question.

> As for the demo/services/naming example, i've tested it and it seems to
> work. What i don't understand is that i'm trying to replicate the example
> with the same exact code except the if(CORBA::is_nil(<variable>)) part
> because both nsobj and nc variables are NOT NULL  i.e. 0x13f6d388.

Hmm. One thing is that nsobj and nc variables are NOT NULL from the C++ 
point of view. They are both _var smart pointers allocated statically on 
the stack so they should not be NULL anyway. The question here is if 
nsobj.in() and/or nc.in() are NULL or not, that means if the pointers 
saved into the smart pointers are null or not. That's why 
CORBA::is_nil(var) is usable here and I certainly recommend its usage 

> I don't think there is smth wrong with argv[3] because with TAO it works
> just fine.

I still think this may be a culprit, if you don't believe try to use the 
same corbaloc in demo/services/naming example... Of course I may be 
mistaken here! But such is my instinct here... :-)


Karel Gardas                  kgardas <at> objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
andreis | 12 Oct 12:14 2013

MICO cryptic problem

Hi, my name is Smolenic Andrei and I am a Phd student at the Stefan cel
Mare University of Suceava, Romania. I've reached a point in my research
where I need to compare some CORBA implementations. I've chosen TAO and
MICO. First I've created a TAO based client-server distributed application
and all went well. At the moment I've come to a halt with the MICO
approach. Let me try to explain the problem.

Setup: Windows 7 64 bit / Visual Studio 2010 Ultimate.
I downloaded the MICO sources and built them using the VS compiler (nmake
/f Makefile.win32). All went well so far. Next i've created a console app
to test the connectivity with the naming service.
I've applied the following config to my project:
- added D:\mico\win32-bin and D:\mico\include to C/C++ ->Additional
Include Directories
- added D:\mico\win32-bin\lib to Linker->Additional Library Directories
- added mico2313.lib and micocoss2313.lib to Linker->Input
- i've compiled the classic account idl file and added the resulting
account.h /.cc to the project
- i've implemented the required servant

And the relevant piece of code:

#include "account.h"
#include "coss\CosNaming.h"
int main()
  int argc = 4;
  char*        argv[4];
  argv[0] = "server";
  argv[1] = "-ORBNoResolve";
  argv[2] = "-ORBInitRef";
  argv[3] = "NameService=corbaloc::";

  CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);

  CORBA::Object_var poaobj = orb->resolve_initial_references ("RootPOA");
  PortableServer::POA_var poa = PortableServer::POA::_narrow (poaobj);
  PortableServer::POAManager_var mgr = poa->the_POAManager();

  PortableServer::Servant account_servant = new Account_impl;
  CORBA::Object_var the_account = account_servant->_this();

  CORBA::Object_var nsobj = orb->resolve_initial_references("NameService");
  CosNaming::NamingContext_var nc=CosNaming::NamingContext::_narrow (nsobj);

  CosNaming::Name name;
  name.length (1);
  name[0].id = CORBA::string_dup ("testname");
  name[0].kind = CORBA::string_dup ("");

  nc->rebind (name, the_account);

  return 0;

The problem is that when the narrowing of nsobj to
CosNaming::NamingContext occurs an CORBA::INV_POLICY is raised (but just
in the VS output) and the execution moves on. Then when the rebinding
takes place i get "Access violation reading location 0xfdfdfdfd". It is my
belief that this access violation occurs because the naming service wasn't
properly resolved/narrowed in the first place, not being able to
bind/rebind to a 'fake' naming context.

I have searched around the web for a solution, i've documented myself
about the policies, about the exception itself but i have yet to find an
answer about what's going on.

I start the naming service daemon with the following command:
nsd -ORBNoResolve -ORBDebug All -ORBIIOPAddr inet:

Maybe if someone has the time to give me a hint I would greatly appreciate
it. Thanks,

Smolenic Andrei

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
Michael Powell | 15 Feb 13:11 2013

Cross platform MICO builds


I am entering a project where we decided C++ was the way to go. C++/boost core engine, devices to be I2C exposed over a distributed object architecture (enter CORBA potentially), and so on, to enable distributed development potentially off-device, as well as on-device in production.

I am no stranger to distributed object technology stacks, like COM-family, web services including WCF, and even a little CORBA, but it has been several years for CORBA, so need a little practical guidance, specially for targeting cross-platforms.

Development would occur on a Windows-based system and target ArchLinux/ARM. What are our options? We can build the ORB to run on either platform? Can it be statically linked with the client/server? Better to dynamically link and let it run as a service?

However if performance suffers and the advantages of getting out of the middle tier protocol management business aren't there, like can we talk client/server over different asynchronous TCP/IP ports, then we may end up rolling our own infrastructure. Not my first choice, I'd rather focus on speed to market, but this is what we need to know.

Other than that, I'm unafraid of the age of CORBA, it's been around for A WHILE (can you believe the first specifications were out in 1991?), so I expect implementations to be nearly as solid as their age would allow.

Thank you...



Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
Thomas Schmidt | 22 Jan 02:14 2013

Thousands of MICO::GIOPSimpleProf objects?


I've just implemented some collections realizing some CosCollection interfaces. A collection is typed at run-time through a CosCollection::Operations object. It offers a collection some methods for element type checking and for ordering. So there's really a lot of communication between a Collection and its Operations object.

After a few seconds of intensive entering, removing or looking up elements in a collection things become slower and slower and slower, …

Some debugging shows that after a few seconds about 40.000 MICO::GIOPSimpleProf objects where created in the context of the Operations process. This process only runs exactly 2 Operation objects as default servants of a POA with NON-RETAIN policy.

After a code review of MICO 2.3.13 (the version in use) I found that profiles where entered - using IOR::add_profile() - into a container of type IOR::IORProfileVec but will only be erased - using IOR::del_profile() - on POA creation. I think computing will become slower due to the lookup loop in IOR::add_profile(). It seems that those MICO::GIOPSimpleProf objects were added in MICO::GIOPCodec::get_target().

Does anyone have a bug fix? Do we really need to add so much profile objects? When do they have to be destroyed? Wouldn't be a container with faster lookup methods a better type for IOR::IORProfileVec?

I'm developing in C++ on MacOSX 10.8.2 in Intel-32bit mode. Applications are running using GIOPVersion 1.2 and IIOPVersion 1.2. I've Threads enabled and switched on -ORBThreadPool and -ORBThreadPerConnection.

Please help, I don't really understand how to fix this bug.


Thomas Schmidt
Velgen 1
D-29582 Hanstedt
Tel: +49-4134-236339
Mobil: +49-151-23095598
Skype: ThCSchmidt
PGP: Key-ID: 0x810B6206

Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net