Release of 0.18

Post by **wmayer** » Mon Apr 01, 2019 8:06 am

=> FreeCAD crashes with this message on console. On next restart the language settings have changed. Switching back produces the same crash.

Can you run FreeCAD inside a debugger so that we get the call stack? Maybe it gives us a hint of the reason of the failure.

Besides I noticed that the complete menu is unavailable if I start from console. I have to switch to another application and back to get it. This does not happen if I start by clicking the icon.

If am not totally wrong then by double-clicking the icon some arguments are passed to the executable that are forwarded to Qt.
See: https://github.com/FreeCAD/FreeCAD/blob ... .cpp#L2062

looo · Post by **looo** » Mon Apr 01, 2019 8:18 am

hmm, there is definetly something wrong. I am not able to create a cube in Part. And any line drawn with draft will crash the programm. This doesn't happen when I launch FreeCAD from the conda-environment. And I also think I tested such basic stuff before uploading.

edit: and suddenly it works again? Now I am totally confused.

looo · Post by **looo** » Mon Apr 01, 2019 10:16 am

wmayer wrote: ↑Mon Apr 01, 2019 8:06 am => FreeCAD crashes with this message on console. On next restart the language settings have changed. Switching back produces the same crash.

Can you run FreeCAD inside a debugger so that we get the call stack? Maybe it gives us a hint of the reason of the failure.

not a debugger output, but this is what is reported after the crash.

Code: Select all

abort() called
*** error for object 0x7f87a695e2b8: pointer being freed was not allocated
 

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff50112b66 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff502dd080 pthread_kill + 333
2   libsystem_c.dylib             	0x00007fff5006e1ae abort + 127
3   libsystem_malloc.dylib        	0x00007fff5016c822 free + 521
4   libc++abi.1.dylib             	0x000000010f867d69 __cxa_end_catch + 137
5   libFreeCADGui.dylib           	0x000000010a826f79 Gui::GUIApplication::notify(QObject*, QEvent*) + 409
6   libQt5Core.5.dylib            	0x000000010c53b478 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 168
7   libQt5Widgets.5.dylib         	0x000000010bd67ea9 QActionPrivate::sendDataChanged() + 105
8   libFreeCADGui.dylib           	0x000000010a853571 Gui::Command::applyCommandData(char const*, Gui::Action*) + 81
9   libFreeCADGui.dylib           	0x000000010ab1bdf9 Gui::MainWindow::changeEvent(QEvent*) + 201
10  libQt5Widgets.5.dylib         	0x000000010bdbbc6c QWidget::event(QEvent*) + 2060
11  libQt5Widgets.5.dylib         	0x000000010becb3e4 QMainWindow::event(QEvent*) + 1108
12  libFreeCADGui.dylib           	0x000000010ab111bd Gui::MainWindow::event(QEvent*) + 1229
13  libQt5Widgets.5.dylib         	0x000000010bd74bd8 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 232
14  libQt5Widgets.5.dylib         	0x000000010bd761be QApplication::notify(QObject*, QEvent*) + 478
15  libFreeCADGui.dylib           	0x000000010a826e39 Gui::GUIApplication::notify(QObject*, QEvent*) + 89
16  libQt5Core.5.dylib            	0x000000010c53b478 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 168
17  libQt5Core.5.dylib            	0x000000010c53c608 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 840
18  libqcocoa.dylib               	0x000000011268f3eb 0x11266a000 + 152555
19  libqcocoa.dylib               	0x000000011268fd50 0x11266a000 + 154960
20  com.apple.CoreFoundation      	0x00007fff28013be1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
21  com.apple.CoreFoundation      	0x00007fff280cb4bc __CFRunLoopDoSource0 + 108
22  com.apple.CoreFoundation      	0x00007fff27ff6b90 __CFRunLoopDoSources0 + 208
23  com.apple.CoreFoundation      	0x00007fff27ff600d __CFRunLoopRun + 1293
24  com.apple.CoreFoundation      	0x00007fff27ff5867 CFRunLoopRunSpecific + 487
25  com.apple.HIToolbox           	0x00007fff272d5d96 RunCurrentEventLoopInMode + 286
26  com.apple.HIToolbox           	0x00007fff272d5a0f ReceiveNextEventCommon + 366
27  com.apple.HIToolbox           	0x00007fff272d5884 _BlockUntilNextEventMatchingListInModeWithFilter + 64
28  com.apple.AppKit              	0x00007fff25585a73 _DPSNextEvent + 2085
29  com.apple.AppKit              	0x00007fff25d1be34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
30  com.apple.AppKit              	0x00007fff2557a885 -[NSApplication run] + 764
31  libqcocoa.dylib               	0x000000011268e991 0x11266a000 + 149905
32  libQt5Core.5.dylib            	0x000000010c53738e QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 414
33  libQt5Core.5.dylib            	0x000000010c53bc19 QCoreApplication::exec() + 377
34  libFreeCADGui.dylib           	0x000000010a79ea26 Gui::Application::runApplication() + 10694
35  FreeCAD                       	0x000000010a780f50 main + 5904
36  libdyld.dylib                 	0x00007fff4ffc2015 start + 1

Post by **wmayer** » Mon Apr 01, 2019 10:38 am

According to this information the function MainWindow::changeEvent is called and the event type must be QEvent::LanguageChange. This invokes Command::languageChange() that internally calls Command::applyCommandData().
Now for one of the commands an exception is raised.

If you can build the macOS binaries yourself you can try this suggestion:
Put the code of Command::applyCommandData() inside a try-catch block which would look like this

Code: Select all


void Command::applyCommandData(const char* context, Action* action)
{
    try {
        action->setText(QCoreApplication::translate(
            context, getMenuText()));
        action->setToolTip(QCoreApplication::translate(
            context, getToolTipText()));
        action->setWhatsThis(QCoreApplication::translate(
            context, getWhatsThis()));
        if (sStatusTip)
            action->setStatusTip(QCoreApplication::translate(
                context, getStatusTip()));
        else
            action->setStatusTip(QCoreApplication::translate(
                context, getToolTipText()));
        QString accel = action->shortcut().toString(QKeySequence::NativeText);
        if (!accel.isEmpty()) {
            // show shortcut inside tooltip
            QString ttip = QString::fromLatin1("%1 (%2)")
                .arg(action->toolTip(), accel);
            action->setToolTip(ttip);
    
            // show shortcut inside status tip
            QString stip = QString::fromLatin1("(%1)\t%2")
                .arg(accel, action->statusTip());
            action->setStatusTip(stip);
        }
    }
    catch (...) {
        printf("%s\n", this->sName);
        throw;
    }
}

This way we know for the last printed name the command class that causes the trouble.

Post by **bernd** » Mon Apr 01, 2019 11:11 am

jmaustpc wrote: ↑Sat Mar 30, 2019 4:24 pm My kids favourite is without any doubt Norm.....because have you seen how cute his cat avatar is?

moved the pets to https://forum.freecadweb.org/viewtopic.php?f=10&t=35372

looo · Post by **looo** » Tue Apr 02, 2019 7:57 am

wmayer wrote: ↑Mon Apr 01, 2019 10:38 am According to this information the function MainWindow::changeEvent is called and the event type must be QEvent::LanguageChange. This invokes Command::languageChange() that internally calls Command::applyCommandData().
Now for one of the commands an exception is raised.

If you can build the macOS binaries yourself you can try this suggestion:
Put the code of Command::applyCommandData() inside a try-catch block which would look like this
Code: Select all
void Command::applyCommandData(const char* context, Action* action)
{
    try {
        action->setText(QCoreApplication::translate(
            context, getMenuText()));
        action->setToolTip(QCoreApplication::translate(
            context, getToolTipText()));
        action->setWhatsThis(QCoreApplication::translate(
            context, getWhatsThis()));
        if (sStatusTip)
            action->setStatusTip(QCoreApplication::translate(
                context, getStatusTip()));
        else
            action->setStatusTip(QCoreApplication::translate(
                context, getToolTipText()));
        QString accel = action->shortcut().toString(QKeySequence::NativeText);
        if (!accel.isEmpty()) {
            // show shortcut inside tooltip
            QString ttip = QString::fromLatin1("%1 (%2)")
                .arg(action->toolTip(), accel);
            action->setToolTip(ttip);
    
            // show shortcut inside status tip
            QString stip = QString::fromLatin1("(%1)\t%2")
                .arg(accel, action->statusTip());
            action->setStatusTip(stip);
        }
    }
    catch (...) {
        printf("%s\n", this->sName);
        throw;
    }
}
This way we know for the last printed name the command class that causes the trouble.

Thx, but I can't test this currently.

Post by **yorik** » Wed Apr 03, 2019 3:31 pm

Regarding py2 / py3 and which should be the default, my rather conservative view would be that where py2 is still the default on a distro, we should use the same for 0.18, as its objective is to be stable, not have people find and report problems. But we should switch in 0.19.
But it's not a strong opinion... Many apps don't follow this anymore.

Mark Szlazak · Post by **Mark Szlazak** » Wed Apr 03, 2019 5:06 pm

yorik wrote: ↑Wed Apr 03, 2019 3:31 pm Regarding py2 / py3 and which should be the default, my rather conservative view would be that where py2 is still the default on a distro, we should use the same for 0.18, as its objective is to be stable, not have people find and report problems. But we should switch in 0.19.
But it's not a strong opinion... Many apps don't follow this anymore.

I think this sentiment is to risk averse for nothing more than a switch of default. It's time to move on, after all this was suppose happen in 0.17.

triplus · Post by **triplus** » Wed Apr 03, 2019 11:38 pm

We are talking about the release version of FreeCAD. Therefore believing forcing all users to use Py3/Qt5 version will somehow help FreeCAD moving forward. When some string related issue will emerge or Save picture tool won't be working on Linux, nothing will move forward. FreeCAD 0.18 will stay as is, issues included!

As for the next development version, that will for sure be Py3/Qt5 oriented. Around a month or two back, majority of developers said, they moved to using Py3/Qt5 toolchain. Therefore next version of FreeCAD will likely have mature Py3/Qt5 support and on Py2/Qt4 side there will for sure be issues introduced.

From FreeCAD 0.18 point of view it therefore makes sense to provide both Py2/Qt4 and Py3/Qt5 builds, whenever feasible, as for the AppImage, best to discuss further in the dedicated thread:

https://forum.freecadweb.org/viewtopic. ... 1&start=10

Post by **kkremitzki** » Thu Apr 04, 2019 12:57 am

I think it's reasonable to have Python 3 as default, since fallback to Python 2 is fairly easy.

Release of 0.18

Re: Release of 0.18

Re: Release of 0.18

Re: Release of 0.18

Re: Release of 0.18

Re: Release of 0.18

Re: Release of 0.18

Re: Release of 0.18

Re: Release of 0.18

Re: Release of 0.18

Re: Release of 0.18