Realm 0.95.0 sometimes crashes when loading the default Realm following a migration. This happens infrequently, and we haven't yet been able to reproduce it in a debugging environment. We are using Realm-Cocoa, but calling from a Swift endpoint.
var config = RLMRealmConfiguration.defaultConfiguration()
config.schemaVersion = 3
config.migrationBlock = { (migration, oldVersion) -> Void in
...
}
RLMRealmConfiguration.setDefaultConfiguration(config)
RLMRealm.defaultRealm()
Here is the backtrace
0x100313ae0 [void realm::util terminate<unsigned long, unsigned long>(char const*, char const*, long, unsigned long, unsigned long) ] (terminate.hpp:45)
...
...
0x10030c44c [realm::SharedGroup SharedGroup(realm::Replication&, realm::SharedGroup::DurabilityLevel, char const*) ] (group_shared.hpp:975)
0x1003073a0 [RLMRealm initWithPath:key:readOnly:inMemory:dynamic:error:] (RLMRealm.mm:235)
0x10030821c [RLMRealm realmWithConfiguration:error:] (RLMRealm.mm:400)
0x100307a98 [RLMRealm defaultRealm] (RLMRealm.mm:302)
...
Is there anything we can do to safeguard against this crash? Does the migration function need to be wrapped in an autoreleasepool block, as per issue #1589?
Whenever you see realm::util terminate in your stack trace, it's likely because an internal consistency assertion in Realm has failed, and generally indicates either a corrupt file or a bug in Realm itself. If you have access to the device logs (for example if you received this crash report using a service like Crashlytics or Hockey), you should see a message printed by the assertion failure.
The best thing you can do in these cases is to report the issue to the realm team (help#realm.io) with as much information as possible to allow us to reproduce the issue, and investigate further. We're generally pretty responsive.
Related
I need to detect the application get exit as normal or crash. QProcess have the finished() signal and can get the exit code. But i need this exit code for QApplication when the application get crash or close.
When your process crashes, it's gone. The crash means that the process has finished because of an unhandled exception. Your job should be to prevent the crash from happening. In other words: handle the exceptions. Note that the exceptions may not be C++ exceptions, they may be low-level platform-specific mechanisms, such as native exceptions on Windows or signals on UNIX. You'd have to handle those, but recognize that the underlying issue is not fixed merely because you catch such an exception. You must assume that the state of your application has been corrupted, and the only safe thing to do is to exit ASAP anyway. For example, do not try to modify any files: you're likely to corrupt them.
I don't think this is something you can do just like that. Reading the value returned by QApplication::exec() is related to the Qt infrastructure:
Enters the main event loop and waits until exit() is called, then
returns the value that was set to exit() (which is 0 if exit() is
called via quit()).
Usually your main looks like this:
#include <QApplication>
int main( int argc, char **argv )
{
QApplication a( argc, argv );
// Initialize your widget(s)
return a.exec(); // You can store this and check its value
}
However if I'm not mistaken this doesn't include handling a crash of your application (segmentation fault, unhandled exception etc.). In Linux people usually use a script which starts the application and then reads its exit code after the application quits or crashes. If you use Linux you can use echo $? to read the exit code from the bash scrip (or its equivalent for a different shell) and then do something based on its value.
Note also that you can at least do some exception handling since some crashes result in exactly that - an exception that has been thrown for some reason and has not been processed properly. Unhandled exceptions in Qt get propagated to the top level (that is QCoreApplication).
I was investigating a memory leak with the application written in C# & C++. Once I have isolated it to couple of C++ components with PerfMon log and WinDbg/SOS debugging I tried to use UMDH (gflags enabled with +ust) to compare snapshots and find out which heap allocations were leaking memory.
At end the leak was found by a manual review of code. The sample code snippet below.
char *p = new char[size];
// use the pointer
delete p; <---- MEMORY LEAK
I was wondering why UMDH didn't catch this ? UMDH never reported this as an issue in the comparison log. Would WinDbg heap commmands would have helped to point out the leak ?
Does anyone understand what this RocksDB error refers to ?
/column_family.cc:275: rocksdb::ColumnFamilyData::~ColumnFamilyData():
Assertion `refs_ == 0' failed. Aborted (core dumped)
This is an assertion failure raised by RocksDB, and it intentionally terminates the execution of the program.
In general, assertions are used by programmers to ensure certain invariants in the program. Assertions have some runtime overhead, and therefore can be completely disabled. Often they are compiled into development or debug builds, but are omitted for production builds.
When an assertion fails, the program execution is intentionally aborted immediately by calling std::abort. This may lead to your OS writing a core dump (as it obviously did as the above message reveals), but if and where core dumps are written depends on the OS configuration.
In case of this specific assertion, the destructor of rocksdb::ColumnFamilyData raised the assertion because it requires its refs_ member to have a value of 0. refs_ is a reference counter and it makes sense to assert that no references are actually held when the object's destructor is called.
From just looking at the destructor code, it is unclear whether this is a bug in the RocksDB library itself, or an error caused by using it the wrong way, e.g. destroying column family objects when they are still in use by other objects.
For reference, here's the code part that raised the assertion (currently on line 365 in file rocksdb/db/column_family.cc):
ColumnFamilyData::~ColumnFamilyData() {
assert(refs_.load(std::memory_order_relaxed) == 0);
If the error persists, it may be useful if you provide the code that uses RocksDB here. Otherwise it may be impossible to find the error source.
The core dump may also provide useful information, because it contains the stack trace of the code that actually invoked the object's destructor.
I noticed that all column_family.cc errors (core_dumped, memory_order_relaxed and etc) occur after incorrect rocksdb installation. In my vagrant script i found true way.
instead of use
https://github.com/facebook/rocksdb/blob/master/INSTALL.md
i create script
cd /opt
git clone https://github.com/facebook/rocksdb.git
cd rocksdb
git checkout tags/v4.1
PORTABLE=1 make shared_lib
export LD_LIBRARY_PATH=/opt/rocksdb
LD_LIBRARY_PATH add better to your environment path(.bash_rc or /etc/environment)
Assertion refs_ == 0 fails on ~ColumnFamilyData() means the reference count of a column family is not zero when the column family is deleted. Most likely you have some un-deleted column family handles before closing the DB. Note that all column family handles must be deleted before closing the DB. Otherwise the assertion will fail.
// Before delete DB, you have to close All column families by calling
// DestroyColumnFamilyHandle() with all the handles.
static Status Open(const DBOptions& db_options, const std::string& name,
const std::vector<ColumnFamilyDescriptor>& column_families,
std::vector<ColumnFamilyHandle*>* handles, DB** dbptr);
To fix such assertion failure, making sure you delete all column family handles before closing the DB.
I’m new to DBus, but I’m trying to use it in two Qt applications on an embedded device. I have a very simple interface that consists of one slot:
QString SendMessage(const QString &cmd);
The server application is then using the following code to start the connection:
DbusService* dBus = new DbusService;
new interfaceIfAdaptor(dBus);
QDBusConnection connection = QDBusConnection::sessionBus();
bool ret = connection.registerService("com.domain.project.interface");
qDebug() << "returns" << ret;
ret = connection.registerObject("/", dBus);
qDebug() << "returns" << ret;
This works fine on the desktop. In the embedded system, the connection.registerService function returns false. As a result, any messages to the server fail. I’m not sure why. Running ‘ps’ tells me that [dbus-daemon —system] and [dbus-daemon —sesson] are both running.
Finally, I have noticed that Qt Creator complains when I debug the application. I see the following warning messages:
Could not load shared library symbols for 10 libraries, e.g. /opt/arm/lib/libQtDBus.so.4.
Use the “info sharedlibrary” command to see the complete listing.
Do you need “set solib-search-path” or “set sysroot”?
Could not load shared library symbols for /usr/lib/libdbus-1.so.3.
Do you need “set solib-search-path” or “set sysroot”?
If additional information is required to debug this problem, please let me know. Or if there are useful dbus commands I could run to help figure this out. Thanks!
It turns out the session bus was not getting started on the device. I enabled it, but then I ran into the problem of the address not getting propagated to the environment variables. I can manually set it in a terminal, but I'm not sure how to do the same in Qt Creator.
Anyway, rather than spend more time figuring out the issues with the session bus, I switched to using the system bus. I just had to change the /etc/dbus-1/system.conf file to allow anyone to talk to the system bus and my applications work on the embedded device. I know that's probably not the long term solution, but it works for now.
I have an Qt application for symbian that receives gps data, stores it into a database and tries to post it to a server. First two steps work fine but continuous posting either crashes my application or kills my internet connection.
I have modified my application for debugging purposes so it only does post data to a server in every 10th second. Application runs fine for about 45-90min without any significant memory increase.
After that that I'll get an error from QNetworkReply saying "Cannot allocate memory".
Same time memory usage increases approximately 63500(bytes?).
On next upload I'll get reply that says "Invalid socket descriptor" and after that my QtCreator debug output is filled with "exception on 7 [will do setdefaultif(0) - hack]"
Anyone know what is going wrong here? I can't find errors from my upload code that could be causing this.
Here is my upload script.
void MainWindow::upload() {
//Content of postData below. Using same data on every upload now when tracking the bug
//[{"timestamp":"2010-10-01T17:10:27","latitude":62.1823321,"longitude":25.73226825,"user":6}]
QByteArray postData;
QNetworkRequest request;
request.setUrl(uploadUrl);
this->qnam->post(request, postData);
}
void MainWindow::serviceRequestFinished(QNetworkReply* reply) {
QByteArray bytes = reply->readAll();
if (reply->error() == QNetworkReply::NoError)
{
//nothing in here when debugging
} else {
qDebug() << "-------Reply error: " + reply->errorString();
}
reply->deleteLater();
updateHeapStats();
}
void MainWindow::updateHeapStats() {
#ifdef Q_OS_SYMBIAN
TInt mem, size, limit;
User::Heap().AllocSize(mem);
size = User::Heap().Size();
limit = User::Heap().MaxLength();
qDebug() << "**DEBUG MEMORY - > Memory: " << QString::number(mem);
qDebug() << "**DEBUG MEMORY - > Heap limit: " << QString::number(limit);
qDebug() << "**DEBUG MEMORY - > Heap size: " << QString::number(size);
#endif
}
Allmost forgot, I have tested this with Nokia N97mini, 5230 and 5800 and they all behave same way.
edit. Forgot to mention that when internet connection "dies" I still can see that 3G is on but connecting to internet with web-browser fails. When I close the application and try to connect to internet with browser it says "Web: Memory full, ..."(web requests from apps works fine) I'm using Nokia Energy profiler and it doesn't show any signs of memory being full. Even tested this and started 2 games, ovi maps and tons of other applications and they worked fine even though they consumed over 40MB of memory.
With the caveat that the only networking code I do in Qt is on a desktop platform and even then I need to look it up, I don't see anything obvious. I also know that in my own code deletelater() sometimes has a different idea of what "later" is than I do. I don't have time to look it up and may be wrong here, but I think deletelater() actually runs on the event thread, and if your event thread is always busy, when will it have time to delete the object? For debug purposes, I would replace deletelater() with delete (and really, there's no reason to use deletelater() unless you've got a parent/child relationship that you need to clean up, and there might be a way to manually remove the child from the parent so you don't need to worry about dangling pointers when you call delete).
I also don't know the accuracy of your memory consumption test. Does the allocated memory test refer to the current thread? The current process? Does a program received a "chunk" of memory from the heap that it simply managers on its own and it isn't permitted to use more than? I think you know this framework much better than I do; these are just some thoughts for you to try.