Arp::System::Commons::Io::Directory problem

PLCnext Technology & PLCnext Controls
1

In a cpp componant code i’m trying to use the Arp::System::Commons::Io::Directory

The following code do a magic crash :slight_smile:

auto entry2 =Arp::System::Commons::Io::Directory::TryGetFileEnumerator(path, "*.json", true).get();
      try {
        log.Info("entry2.MoveNext()");
        entry2->MoveNext();
        log.Info("entry2.GetC()");
        log.Info(entry2->GetCurrent());
      }
      catch (std::exception& e) {
        log.Info(e.what());
      }
The call to movenext generate unhandled exception
 Eclr                             ERROR - Vectored exception 6 at 0x7fdf5c3e476b is thrown, Rfp=0x7fdf46ffcc00, Rsp=0x7fdf46ffcac0, Rlr=(nil)
23.11.22 13:00:04.591 Eclr                             ERROR - VEH: No managed eCLR context found
23.11.22 13:00:04.594 Arp.System.Commons.Runtime.SignalHandler           FATAL - Signal SIGSEGV occured.
Stacktrace:
  at: VectoredHandler_SIGSEGV(int, siginfo_t*, void*)
  at: /lib/libc.so.6(+0x41910) [0x7fdfb7e31910]
  at: L02TestFileManager::L02TestFileManagerComponent::delegateThreadFileParserBody(void*)
  at: void Arp::System::Core::Impl::MethodFunctor<void (L02TestFileManager::L02TestFileManagerComponent::*)(void*)>::Invoke<void*>(void*, void*&&)
  at: Arp::System::Commons::Threading::Thread::RunThread(Arp::System::Commons::Threading::ThreadBinaryCompatibilityExtensions*)
  at: Arp::System::Commons::Threading::Thread::RunInternal(void*)
  at: Arp::System::Ve::Internal::Linux::ThreadService::RunInternal(void*)
  at: /lib/libc.so.6(+0x8a8f2) [0x7fdfb7e7a8f2]
  at: /lib/libc.so.6(+0x10c7c0) [0x7fdfb7efc7c0]

How to use directory? Regards

2

Hello alexandre l,
I’ll verify this issue and give you a feedback asap.

In the meantime you can try to use the FB: PBCL_FileList in PLCnextBase Library ( PLCnext Store | PLCnextBase ):
The Function block „PBCL_FileList“ list files of a directory and provides general information about the files and folders of a given directory. The information is requested via shell interface.
Attention: This function block buffers the file information internally to increase access times. Therefor it should not be used for directories with more than 1000 files.

BR Eduard

3

Hello alexandre l,
you are using the „.get“ method of „shared_ptr_base“ https://en.cppreference.com/w/cpp/memory/shared_ptr/get
This is the root cause of the exception error:
image.png
If you use instead „auto“ Datatype the expected Datatype as return value/pointer, then the compiler will generate the following error message:
Code:
IEnumerator::Ptr entry2 = Arp::System::Commons::Io::Directory::TryGetFileEnumerator(„/opt/plcnext“, „", true).get();
Compiler Error:
[cmake]: C:/PLCnext/workspace/CppArpDirectory/src/CppArpDirectoryProgram.cpp: In member function ‚virtual void CppArpDirectory::CppArpDirectoryProgram::Execute()‘:
[cmake]: C:/PLCnext/workspace/CppArpDirectory/src/CppArpDirectoryProgram.cpp:15:131: error: conversion from 'std::__shared_ptr<Arp::IEnumerator<Arp::BasicString >, __gnu_cxx::_S_atomic>::element_type’ {aka 'Arp::IEnumerator<Arp::BasicString >'} to non-scalar type ‚Arp::IEnumerator<Arp::BasicString >::Ptr‘ {aka ‚std::shared_ptr<Arp::IEnumerator<Arp::BasicString > >‘} requested
[cmake]: 15 | IEnumerator::Ptr entry2 = Arp::System::Commons::Io::Directory::TryGetFileEnumerator(„/opt/plcnext“, "“, true).get();

Please use the documented public member function of the used class:
PLCnext API Documentation: Arp::System::Commons::Io::Directory Class Reference

Please also note restrictions on file access in real-time context e.g. that the high number of files in the directory has a direct impact on the execution time of the method.
BR Eduard

4

Hello Alexandre,
the error is caused by this statement:
IEnumerator::Ptr entry2 = Arp::System::Commons::Io::Directory::TryGetFileEnumerator(„/opt/plcnext“, „*“, true).get();

The return type of this expression
Arp::System::Commons::Io::Directory::TryGetFileEnumerator(„/opt/plcnext“, „*“, true).get()

is IEnumerator* (native pointer)
but not
IEnumerator::Ptr (shared pointer)

because of the green marked .get() statement. So that the automatic object of type IEnumerator::Ptr which is returned by TryGetFileEnumerator is deleted automatically, which causes a deletion of the native pointer, which is hold by the shared pointer. Thus, the error is caused just by the green marked .get() statement.

The rule when working with smart pointers is, never mix smart pointer and native pointer, e.g. by calling .get() or .release() on the smart pointer, except there is a very good reason for it and the programmer knows exactly, what he is doing. Mixing native pointer and smart pointer disturbs the implicit memory management of the smart pointer.

The error is caused by customer code, so that this error might be closed from firmware point-of-view.

BR Eduard