I am trying to integrate SQLite library into RTP application on VxWorks. I built SQlite and link against it statically. I run simple test that works well on other systems. The test is realy primitive one: sqlite_open(), sqlite_exec(), sqlite_close(). Parameters are correct (works on other systems).
I experience SIGSEGV (signal code 11). I traced down to the point of crash with "printf()s" and discovered that it crashes after pthread_mutex_lock() call. What is interesting - it returns from the function call and then crashes. I checked the stack size (having a taskDelay() afore actual crash). Stack is big enough and far from its limit.
I try to build SQlite with SQLITE_HOMEGROWN_RECURSIVE_MUTEX and without. And I build all the time with SQLITE_THREADSAFE 1.
If someone has experienced something like that and managed to fix it - please let me know.
Here are few details, jut to outline them.
VxWorks wersion: 6.8
SQlite sources: 3.7.16.1
Development environment: Windriever
CPU Architecture: PowerPC
Thanks in advance
I have found it. I had no pthreads in my VxWorks OS. Now it works.
The strange thing is that there is no way to verify that while building an application against pthreads library.
There is no easy way to do that, but at least some kind of "stub" function, rhater than SIGSEGV. Or am I asking too much for that kind of money?
Related
I'm starting to use Visual Studio Code for my IoT work, including microprocessor coding. I've used Arduino and Teensy, my current project is using a Particle Electron.
I need a head start finding the correct add-ins and/or approach to debug an Electron. I believe my 2 unknowns are:
What VSCode extension should I use, does one exist, do I need one?
Do I require a piece of hardware, like the Particle debug shield, ST-Link J-Link, etc.?
Is there a common interface/protocol I should be looking for, to
measure VSCode compatibility for debuggers, etc.?
Any input would be appreciated.
Thanks
-John
You can find answer to your query here :
Spend some time reading its documentation.
compiling details can be found here.
I have a program in julia and I know it took a lot of memory. I want to know where it is happening.
How can I monitor the code or profiling for finding the problem?
Please read the manual: https://docs.julialang.org/en/v1/manual/profile/index.html
Profiling for memory use discussed at the bottom. The Juno IDE has some nice tools for interacting with the profiler: http://docs.junolab.org/latest/man/juno_frontend/#Profiler-1
I am working on one project which is a standalone javafx application. It will run 24*7*365 days continuously.
So, i have a question in mind.
which things we need to consider for running this application smoothly and with high performance for 24*7*365?
Please guides me sir, regarding it.
Details for used things are as follows for Reference :-
Used java version :- 1.8.0_121
Available Ram :- 2GB
Allocated Memory for application :- -Xmx1524M
Hardware Configuration :- Processor - Intel Atom CPUD425# 1.80GHz x 2
OS :- 32 Bit Fedora 15
I will probably state the obvious here, but OutOfMemory errors are the main thing you should worry about. A small glitch in your code/program could make your app die fast or run extremely slow under memory pressure.
I would say that you need to enable garbage collection logs and monitor those. Also is there a way for a javafx app to actually use another instance if the current one is facing issues? There are tools for that under different apps, but not sure about javafx... I mean can you automatically shut down (and collect heap data) the current running application and automatically start a new one (so that later you can analyze what actually happened)? It might not be feasible, and if it's not, you should have enough stress tests before you actually lunch it into production.
One thing you should check first is whether your system suffers from the notorious memory problems that some Linux graphics drivers have. See for example my answer to this question here on SO:
Javafx growing memory usage when drawing image
I am new to cross compiling and willing to get started with cross compiling Qt for beagleboard. Can some one give me specific instructions for this or recently tried tutorial. Please do not assume any knowledge on my part so can not handle instructions like "you may have to edit this to your architecture". I have a few important questions.
how to build Angstrom tool chain and how to prepare it for cross compiling. (I have tried the anstrom web site and never found such random instrutions in my life).
How to cross compile Qt after installing.
The process is a little daunting for the first time developer. I used this blog to give me a start,
http://treyweaver.blogspot.com/2010/10/setting-up-qt-development-environment.html
but like all of the other instructions, sometimes there will be deviations. It took me a while to sort it all out. You are going to have to read and study to to this. It is a worthy thing to do however. As far as Angstom, there are ready made images available. I started with that. You should use Ubuntu to do all of your work. Linux makes it a lot easier.
The article Porting Qt for Embedded Linux to Another Operating System lists five things you have to do to port Qt for Embedded Linux to another OS. From the article:
There are several issues to be aware of if you plan to do your own port to another operating system. In particular you must resolve Qt for Embedded Linux's shared memory and semaphores (used to share window regions), and you must provide something similar to Unix-domain sockets for inter-application communication. You must also provide a screen driver, and if you want to implement sound you must provide your own sound server. Finally you must modify the event dispatcher used by Qt for Embedded Linux.
Is it really this easy to port Qt to another OS, or have i missed some information?
Another important component to port would be QAtomic, to ensure that you can have atomic operations and implicit sharing working well. See also
http://labs.trolltech.com/blogs/2007/08/28/say-hello-to-qatomicint-and-qatomicpointer/
Since Qt has been ported a large number of times it seems logical that it would be inherently simple. However the issue really is on the platform you are porting to and how many features it currently supports.
Assuming you find all those things easy, then the port is easy.
After investigating this in more detail I have come to the conclusion that the article "Porting Qt for Embedded Linux to Another Operating System" assumes that you are porting Qt to a very "linux-like" OS.
I have attempted this and currently making progress.
Some difficulties:
IDE - I have to manually add all Qt files and fight the compiler with #ifdefs until it builds with all dependencies in place.
Linux(ness) - I've had to disable all Linux/Windows things that are not supported in my target OS: threads, sockets, processes. Even the timers are slightly different.
Tips:
Start small : I compiled QtCore as a standard lib within my IDE, next up is QtGui which is a behemoth compared to QtCore.
I plan to run only a single QThread, so I have to artificially made a Thread object to avoid null pointers. You cannot compile out Thread information as it is key to all QObjects.
So far I have an qeventloop running within a qcoreapplication.
I wrote some inline assembly but had serious difficulties with my IDE and compilation. I left it in C++ and let the assembler handle it for me. Because I am single-threaded, I am not too concerned with shared data/ exclusive access as required by the atomic operations.