Notice:
I think I figured out why its not working. It was the line libusb_device_handle**. I am trying to create multiple handles. Is this correct or am I only allowed one handle. Is it because I am using pointers wrong? Do I need to create multiple contexts for separate devices?
Using libusb-1.0 am trying to get the device descriptor for a usb device. The code compiles and no error messages are displayed, but it ends in a segmentation default. I have narrow it down to a cause. Opening a libusb_device and declaring a libusb_device_descriptor variable causes the seg fault.
#include <libusb.h>
int main(int argc, char const *argv[])
{
libusb_context* context;
libusb_device** devices;
libusb_device_handle** handles;
libusb_device_descriptor descriptor;
libusb_init(&context);
libusb_set_debug(context,LIBUSB_LOG_LEVEL_WARNING);
int count = libusb_get_device_list(context,&devices);
for(int i = 0u; i < count; ++i)
{
libusb_open(devices[i],&handles[i]);
libusb_close(handles[i]);
}
libusb_free_device_list(devices,1);
libusb_exit(context);
return 0;
}
Related
I'm making a simple Qt app that reads stuff from a CSV file and generates a PCAP data file out of it for reading by some other software.
And so soon as I invoque pcap_open_dead, pcap_dump_open or pcap_dump, I get no more console output upon running my small converter. Even the Hello World that comes at the beginning of the main doesn't show up any more. From the code below, if I simply comment out those three methods, the console output and "Hello World" come back.
Being new and therefore clueless about pcap, I ask for help.
#include <QCoreApplication>
#include <iostream>
#include "pcap.h"
using namespace std;
struct pcapWriter_S
{
bool isAvailable;
int m_OutPcapIpId;
pcap_t* m_OutPcapHandle;
pcap_dumper_t* m_OutPcapFile;
}m_pcapWriter;
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
cout << "Hello World!" << endl;
//m_pcapWriter.m_OutPcapHandle = pcap_open_dead(DLT_EN10MB,65535);
//m_pcapWriter.m_OutPcapFile = pcap_dump_open(m_pcapWriter.m_OutPcapHandle, QString("tmp_csv_out.pcap").toAscii().data());
m_pcapWriter.m_OutPcapIpId = 1;
if (m_pcapWriter.m_OutPcapFile != 0)
{
m_pcapWriter.isAvailable = true;
}
QByteArray pkt_data;
// Omitted code to generate pkt data from input file
m_pcapWriter.m_OutPcapIpId++;
//pcap_dump((unsigned char*)m_pcapWriter.m_OutPcapFile, &header, (unsigned char*)pkt_data.data());
return a.exec();
}
Somehow this was due to me calling pcap_open but not pcap_close quite yet. In between console stuff gets lost - can't swear it gets written on the pcap thing but it blocks the console anyway.
I was trying to use a for each [Modern c++ style] but the code is crashed each time!
It was something like :
for(auto &k:mimeData->formats())
{ ... }
And later out of my surprises I found that the QStringList returned by formats is either invalid or completely separate object though the internal data is ought to be same!
So I tried to figure out in more simple example :
#include <iostream>
#include <string>
#include <list>
#include <QCoreApplication>
#include <QMimeData>
using namespace std;
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
cout<<boolalpha;
list<string> ls;
cout<<(ls.begin() != ls.end())<<"\n";
QStringList qsl;
cout<<(qsl.begin() != qsl.end())<<"\n";
QMimeData qme;
cout<<(qme.formats().begin() != qme.formats().end())<<"\n";
cout<<"OMG! is it empty? -> "<<qme.formats().empty()<<"\n";
return a.exec();
}
The output is something like :
false
false
true
OMG! is it empty? -> true
Until or unless I take an rvalue reference I cant decide what is happening internally!
I really need a solution to use it with range based for loops, not Qt's foreach!
P.S. I dont want to copy it to avoid O(n).
Looking at the docs, there's no guarantee QMimeData class keeps QStringList of supported formats (http://doc.qt.io/qt-4.8/qmimedata.html#formats) as a field.
The source code supports that (Qt5.4/Src/qtbase/src/corelib/kernel/qmimedata.cpp:593):
QStringList QMimeData::formats() const
{
Q_D(const QMimeData);
QStringList list;
for (int i=0; i<d->dataList.size(); i++)
list += d->dataList.at(i).format;
return list;
}
Therefore this list is constructed on every call to formats(). Farther calls to it will always yield a separate container.
Since you do need to preserve it to traverse it, I'd recommend keeping a local copy of it. Do note that C++11 allows for it to be moved constructed (or in fact - optimized even better).
I'm having a problem writing directly to a disk, I'm trying to write a Qt version of the old PARTCOPY (now obsolete on systems incompatible with 16-bit)
I'm using Windows 10, and have my program elevated to Administrator privileges.
Every time I try to open "\\.\A:" in with QIODevice::WriteOnly, I get an error message "The parameter is incorrect".
Using Visual Studio step-wise debugging, I think I've found the problem occurs in QFSEnginePrivate::nativeOpen() when tring to execute CreateFile().
The line:
// WriteOnly can create files, ReadOnly cannot.
DWORD creationDisp = (openMode & QIODevice::WriteOnly) ? OPEN_ALWAYS : OPEN_EXISTING;
seems to be the cause. If I force the value of creationDisp to be OPEN_EXISTING, then I can get the file opened and I can write to the disk without any further problems. The issue is that I don't know what way I can get this working without using the debugger.
Has anyone found a solution to this?
UPDATE: (test case)
#include <QtCore/qcoreapplication.h>
#include <QtCore/qtextstream.h>
#include <QtCore/qfile.h>
int main(int argc, char **argv) {
QCoreApplication a(argc, argv);
QTextStream cout(stdout, QIODevice::WriteOnly);
QFile f("\\\\.\\A:");
if (!f.open(QIODevice::WriteOnly)) {
cout << f.errorString();
return -1;
}
return 0;
}
You can try these two functions, I write successfully by (1).
bool QFile::open(FILE *fh, OpenMode mode, FileHandleFlags handleFlags = DontCloseHandle)
bool QFile::open(int fd, OpenMode mode, FileHandleFlags handleFlags = DontCloseHandle)
I have this simple code of c,c++, which runs fine:
struct node{
int x;
struct node* next;
};
int main(int argc, char *argv[])
{
int a,b,c;
struct node *root, *node1, *node2, *leaf;
root = malloc( sizeof(struct node) );
//root = NULL;
root->next = 0;
root->x = 12;
system("PAUSE");
return 0;
}
Now if I assign root = NULL or 0, instead of malloc, it gives me this error-
"An access violation (Segmentation fault) raised in your program"
While in the next line i could assign 0 to next pointer. Please explain
In this forum I read segmentation fault occurs when we try to access secured memory space, while operating system defines it like a page fault when the required data is not found in memory. Are they related ? (SF of C, C++ and SF of Operating System)
If you set root = NULL;, it will do exactly that, and will not generate a segmentation fault.
The segfault happens on the next line, when you try to dereference the NULL pointer.
If you comment out the two lines below it, you will observe no segfault.
You cannot and should not dereference A NULL pointer.
I've got a very strange bug while using MPI. A successfully created communicator can't be deleted. A deleting attempt results in FATAL ERROR on all nodes except the ones that are included in communicator group. The minimal working example is below. What do you think about the reason of such strange behaviour?
#include <stdio.h>
#include <mpi.h>
int main(int argc, char* argv[])
{
MPI_Group group_world; // group of MPI_COMM_WORLD
MPI_Group group_new; // new group
MPI_Comm comm_new; // new communicator
int group_new_ranks[3]={10,20,30}; // new communicator's ranks
MPI_Init(&argc, &argv);
MPI_Comm_group(MPI_COMM_WORLD, &group_world); // get group_world - MPI_SUCCESS for all nodes
MPI_Group_incl(group_world, 3, group_new_ranks, &group_new); // get new group - MPI_SUCCESS for all nodes
MPI_Comm_create(MPI_COMM_WORLD, group_new, &comm_new); // create new communicator - MPI_SUCCESS for all nodes
MPI_Comm_free(&comm_new); // FATAL ERROR for all nodes except 10, 20, 30
MPI_Group_free(&group_new);
MPI_Group_free(&group_world);
MPI_Finalize();
return 0;
}
MPI_Comm_create() returns MPI_COMM_NULL to all processes not within the group. You're passing MPI_COMM_NULL to MPI_Comm_free(), which is not allowed.