question

Upvotes
Accepted
1 1 2 2

Assertion failed: pDacsSystem != NULL

Is this a known issue while creating a DACS authorization context? The release libraries work fine, the only debug build has this error. I'm using OpenDACS 8.0.0L1 with RFA 8.1.3.L1 linked statically on Windows 32 bit / Visual C++ 12. Got following error:

Assertion failed: pDacsSystem != NULL, file C:\Jenkins\workspace\RFACPPDEV_RCDEV\OS\VS120-32\rcdev\source\dlib\cppdacslib\src\DacsLibThread.cpp, line 184

Failed stack trace:

NtWaitForSingleObject (ntdll.dll)

WaitForSingleObjectEx (kernel32.dll)

WaitForSingleObject (kernel32.dll)

crt_sig_handler (...]

raise (MSVCR120D.dll)

CrtSetReportHookW2 (MSVCR120D.dll)

VCrtDbgReportW (MSVCR120D.dll)

CrtDbgReportW (MSVCR120D.dll)

CrtDbgReportW (MSVCR120D.dll)

memcmp (MSVCR120D.dll)

abort (MSVCR120D.dll)

wassert (MSVCR120D.dll)

rfa::dacs::CDacsLibThread::runThread (...) [c:\jenkins\workspace\rfacppdev_rcdev\os\vs120-32\rcdev\source\dlib\cppdacslib\src\dacslibthread.cpp:184]

rfa::support::Thread::startWrapper (...) [c:\jenkins\workspace\rfacppdev_rcdev\os\vs120-32\rcdev\source\rfaut\common\support\os\impl\thread.cpp:46]

beginthreadex (MSVCR120D.dll)

endthreadex (MSVCR120D.dll)

BaseThreadInitThunk (kernel32.dll)

RtlInitializeExceptionChain (ntdll.dll)

RtlInitializeExceptionChain (ntdll.dll)


I have following code for creating the context. I checked that dacsAuthSystem is not NULL.

dacsAuthSystem->createAuthorizationAgent( rfac::RFA_String( "some name" ), false /*withCompleteEvents*/ );

The issue is not consistent.

authenticationDACSopen-dacs
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
11.3k 25 8 14

The issue occurs only on Open DACS debug library when application reinitialize Open DACS AuthorizationSystem immediately after uninitializing previous AuthorizationSystem to close connection. The issue can be replicated on dacsSubscribeClient example which is modified to repeat the following sequences: 1. Open daemon connection, 2. Log in, 3. Check subscription permission, 4. Log out, 5. Closing daemon connection. Sleep() call needs to be removed from last step.

        if (pClient != NULL) {
            /******************************************************************
            * Following waiting code is for allowing usage logging process to
            * complete before exiting program.
            ******************************************************************/
            // Remove this Sleep call
            //SLEEP(USAGE_LOGGING_WAIT*1000);

            // Close daemon connection.
            pClient->closeDaemonConnection();
        }

Development has explained that the debug library would build a lot of debug information, so it would cause more delay, then the other transaction such as usage logging is not completed yet. Application have to waiting for usage logging process to complete before it can do next step. However, they cannot find any other solution to avoid the sleep call.

The “SLEEP” added generally is suggested to waiting for other transactions to complete. If no “SLEEP” added, possibly it is ok to continue, possibly it would trigger a failure. This depends on the CPU speed/server performance.
There is potential issue that the usage logging process is still in progress.

I have also suggested another solution to keep the connection to DACS opened. Once the application wants to do permission check, it will just sends login, checkSubscrciption and logout.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
29k 33 11 15

Hello @Sergey Emantayev,

I think this issue you observe may be related with using RFA that is linked statically. You mean "RFA ... static" download?

I have just re-tested the OpenDACS dsdk8.0.0.L1.devkit.all.rrg with RFA shared, rfa8.0.0.L1.win-shared.rrg, debug and release, did not see any issue.

As I find in ReadMe.txt, supplied with all OpenDACS examples, they say "Make sure that there are both RFA X.X and OpenDACS X.X shared libraries are installed in your system", these are the versions, prevalent at the last issue of the examples, shared from RFA 8 will work.

Do not believe OpenDACS is provided as static, or certified with static RFA.

Could you please test with RFA 8.0 shared, available via RFA C++ Downloads to confirm if you observe this issue?

Hope this helps

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Actually, I had a different issue with the shared libraries. Looking in README, I could not find that OpenDACS 8.x is supported on Windows/32 bit... Could you confirm? Should I use OpenDACS 7.x on Windows/32 bit?

Hello @Sergey Emantayev,

You are correct. Apologies, I have missed that you are looking to run on 32 bit Win. You may have to use OpenDACS 7.6 to be supported on 32 bit. RFA 8.1.3.1.L1 shared, the latest, includes 32-bit libraries.


Thank you @zoya.farberov for the clarifications. Now I tried to run OpenDACS 8.x with RFA shared and it worked for me. Can you confirm OpenDACS with RFA 8.1.3.1.L1 shared is supported on Windows / 32 bit?

Upvotes
1 1 2 2

Update: I'm still facing with error with RFA shared both in 7.6.2E4 and 8.1.3.L1, debug binaries on Windows/32 bit. The release binaries work fine. I still need this to work in the debug build. Please advise.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Hello @Sergey Emantayev,

I hear you.

Just confirming that my understanding is correct: you are testing OpenDACS 7.6 or OpenDACS 8 when you see the issue with Debug?

OpenDACS 7.6 (per README) is tested with Microsoft Visual C++ 11.0 32-bit and on MSWin 32bit.

@zoya.farberov, that's right. I've tried these configurations, both static and shared libraries. The debug build on Windows/32 bit has the issue. The stack trace points to a thread initiated by the RFA library, not the user code.