crash in wxMacDataBrowserListCtrlControl::MacSetColumnInfo, was: libwx_macu-2.8.0.4.0.dylib - crash on multiple clicks

[yuv]

newbie's first report here - please forgive me if I (inevitably) make mistakes.

Hugin is a wxWidgets app, currently being polished for release. This nasty bug has been reported by OSX users with crash logs that indicates the crash happened in libwx_macu-2.8.0.4.0.dylib.

< https://sourceforge.net/tracker/?func=detail&atid=550441&aid=1933391&group_id=77506>

It does not happen in Windows and Linux. Is there anything we can do about it?

[wojdyr]

Please report a bug here rather than giving a link.
Try to reproduce the problem in one of the wx samples, because wx developers may not have time to debug your program.
You may also have a look at:
 http://trac.wxwidgets.org/wiki/HowToSubmitTicket

[csomor]

Hi

yes, help us to be more efficient, provide a sample project file/s, walkthrough, perhaps a sample build.dmg (should be debug, so that asserts may trigger, and we get some reasonable source information), eg
3 net.sourceforge.hugin.Hugin 0x00010008 0x1000 + 61448
4 net.sourceforge.hugin.Hugin 0x00015010 0x1000 + 81936
doesn't really help us in a stack trace
looking at wx-part of the stack trace provided I think we might get an event and look at already freed data, an assert should actually popup in this case when using a debug build, I'd like to catch the bug first, better than applying a few blind safety nets, because we really should know what is at the root of the problem first ...

Thanks,

Stefan

[yuv]

Thank you for your positive response.

I have no access to OSX, nor do most hugin developers. Also: I have no experience of C++ debugging. I'm just a coordinator trying to bridge between our users community and the wxWidgets developers in the common interest. That said, I am all ears and will try to understand what you need from me and will try to provide you with it. Please accept my apology if in the process I offend your intelligence by stating the obvious; if I misunderstand what you need and provide useless crap; if I seem to be talking Klingon; if I make any other mistake. Together we can work to bridge the gaps.

Hugin is an application to stitch photos. The basic principle is to take two or more overlapping pictures, identify common features, mark them as control points (CP), align the photos and produce a larger image.

I hope I understand you right, and you need a way to get started / run hugin on your OSX computer.

You can find hugin builds for OSX at < http://hugin.panotools.org/testing/hugin/>

Harry in our community actively maintains them. Current documentation is at < http://wiki.panotools.org/Hugin_Compiling_OSX> and he is working on < http://wiki.panotools.org/Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode>

Once you have the hugin application up and running, you need to feed it with images and generate control points. To spare you the hassle, you'll find everything you need in this 3MB file: . I've prepared for you a project that already has all what you need: < http://www.photopla.net/hugin/dummy_project.zip>

Download it, extract it to a folder and open the .pto project file with hugin.

Inside hugin, to re-create the bug, go to the menu View -> Control Point Table. Hold down the modifier key for multiple selection (on Windows it's the CTRL Key) and click wildy around. There have been mixed reports: many people get the error consistently while a few others can't reproduce it. Some of those who did reproduce it did it with this exact project (though the images were in PNG format).

I hope this helps, and I look forward for to hunt together for this bug.

Yuv

P.S.: Harry reported that he uses 2.8.7 and that he has not yet filed a bug for the version number, maybe you want to check into this too?
< http://groups.google.com/group/hugin-ptx/msg/d8ec24dd08bf22d4>

[yuv]

Harry just produced a debug build:

 http://hugin.panotools.org/testing/hugin/DEBUG/Hugin3088-debug.tgz
 http://hugin.panotools.org/testing/hugin/DEBUG/3088-DEBUG.dmg

I hope this helps.

what is the next step?
Yuv

[csomor]

that's perfect, I've already downloaded your sample project, I'll test now and report back

Thanks,

STefan

[Axel]

crash log of debug build

[Axel]

See the attached file for a stack trace of the debug build provided by Harry. So the new part compared to the logs in the sourceforge issue 1933391 are:

3 net.sourceforge.hugin.Hugin 0x0000ed7c CPEditorPanel::SelectLocalPoint(unsigned int) + 540 (CPEditorPanel.cpp:689)
4 net.sourceforge.hugin.Hugin 0x00013da0 CPEditorPanel::OnCPListSelect(wxListEvent&) + 32 (CPEditorPanel.cpp:1724)

I tried to get some more info by attaching XCode (gdb) before making it crash. Several wired circumstances puzzled me:

1. contrary to the Version line in the crash log, the code base is obviously not 2766 but more likely >= 3066
2. after the crash gdb stopped at line 688 and not 689 as shown in the log
3. the linked wx lib appeared to be no (proper) debug build (judged by XCodes behavior)
4. examining the value of the wxListCtrl struct (m_cpList see below) crashed XCode :-(

Line CPEditorPanel.cpp:688 reads:

m_cpList->SetItemState(LVpointNr, wxLIST_STATE_SELECTED, wxLIST_STATE_SELECTED);

LVpointNr == 2 after the crash and m_cpList itself seemed to have a reasonable value.

[csomor]

Hi Axel

thanks for posting, in the meantime I was able to reproduce the crash, provoking kind of an overflow of events on the list, as you correctly point out the wx version used is not a debug one, thus not helping in debugging and not triggering any asserts while running it. I'm now trying to get an xcode project running, but it isn't going forward too smoothly, so if someone already has that and could put a dmg of the entire folder somewhere this would help.

Best,

Stefan

[yuv]

Thank you, guys!

I will make Harry (OSX builder) and Pablo (main developer) aware of your comments.

Axel, you are right, this is not SVN 2766. hugin is progressing nicely toward release. we have branches in that subversion repository for Google Summer of Code students. The version I linked in my above comment for your perusal is SVN 3088. However I am not sure if Harry rebuilds everything from scratch, or if he just builds those binaries that have changed.

For the rest, you will excuse me, I'm a caveman and I don't know what gdm stands for.

Stefan: I'll let Harry know about the wx Debug version - Mac users in our community are just bringing the OSX build to the next level, we might get lucky and have something. Somebody will keep you posted - if it is me it will be on the weekend.

There was another issue with hugin's CP-List on OSX. Pablo, our main developer, has modified SVN 3091 to use a generic list control and avoid the OSX native ListControl which may fix the two issues that OSX users have with hugin at the moment - the crash reported in this bug and the slowness of the CP-List window.

But it does not solve the issue for wxWidgets, nor for other wxWidgets based applications. If can be of any help, I want to help you find the root of the issue.

Yuv

[csomor]

Hi

yes, I always suggest the use of the wxMAC_ALWAYS_USE_GENERIC_LISTCTRL option when you're close to release, but a) of course I'd like to track down the true problem and b) I have the impression that event handling is occuring immediately in the listctrl event and not just doing an lazy update of the main window, which on mac is always a tricky thing to do, as drawing is more expensive and on newer systems gets blocked if you are redrawing to often. I'm building the externals step by step (had a problem because $OTHERMAKEARGs was getting a space in front of the number from $PROCESSNUM)

Best,

Stefan

[harryvanderwolf]

Hi,

I currently maintain the Hugin OSX bundle. Please note that I'm not a developer, but only a builder.

To let you know how I built the wxMac 2.8.7 libraries on OSX I copy the settings below (lines will most probably been broken due to filed width of the tracker):
===
WxMac compilation

i386 flags

env CFLAGS="-arch i386 -march=prescott -mtune=pentium-m -ftree-vectorize -mmacosx-version-min=10.4 -O2 -g -dead_strip" \

CXXFLAGS="-arch i386 -march=prescott -mtune=pentium-m -ftree-vectorize -mmacosx-version-min=10.4 -O2 -g -dead_strip" \
CPPFLAGS="-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include" \
LDFLAGS="-arch i386 -L/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib -dead_strip -prebind" \
../configure --prefix="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository" --disable-dependency-tracking \
--host="i386-apple-darwin8" --exec-prefix=/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386 --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk \
--enable-monolithic --enable-unicode --with-opengl --enable-compat26 --disable-graphics_ctx \
--enable-shared --enable-debug --enable-debug_flag --enable-debug_info --enable-debug_gdb \
--enable-debugreport ;

ppc flags

env CFLAGS="-arch ppc -mcpu=G3 -mtune=G4 -mmacosx-version-min=10.3 -O2 -g -dead_strip" \

CXXFLAGS="-arch ppc -mcpu=G3 -mtune=G4 -mmacosx-version-min=10.3 -O2 -g -dead_strip" \
CPPFLAGS="-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include" \
LDFLAGS="-arch ppc -L/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib -dead_strip -prebind" \
../configure --prefix="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository" --disable-dependency-tracking \
--host="powerpc-apple-darwin7" --exec-prefix=/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/ppc --with-macosx-sdk=/Developer/SDKs/MacOSX10.3.9.sdk \
--enable-monolithic --enable-unicode --with-opengl --enable-compat26 --disable-graphics_ctx \
--enable-shared --enable-debug --enable-debug_flag --enable-debug_info --enable-debug_gdb \
--enable-debugreport ;

wx-config output for i386 part: ./wx-config --version-full --selected-config --debug --cppflags --cflags --cxxflags --libs

2.8.7.0
mac-unicode-debug-2.8
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386/lib/wx/include/mac-unicode-debug-2.8 -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DWXDEBUG -DWXMAC
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386/lib/wx/include/mac-unicode-debug-2.8 -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DWXDEBUG -DWXMAC
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386/lib/wx/include/mac-unicode-debug-2.8 -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DWXDEBUG -DWXMAC
-L/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386/lib -arch i386 -L/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib -dead_strip -prebind -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -lwx_macud-2.8

(ppc info for wx-config equal except change i386 or ppc )
====
Next to this we patch wxwindows as we had big problems with the images "bleeding through" in the several tab pages of Hugin using wxMAC_USE_CORE_GRAPHICS. When "selectable items" were changed in the "Images" tab or the "Camera änd lens" tab, the underlying images were "bleeding through" thereby obscuring the texts and widgets in the active tab. To overcome this we patch the setup.h as follows:

echo '#ifndef wxMAC_USE_CORE_GRAPHICS' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo ' #define wxMAC_USE_CORE_GRAPHICS 0' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo '#endif' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h

i386 and ppc library merged with lipo

==========
Based on the info above you can see that the libraries were built with debug info. No stripping takes place. I adapted the Hugin Xcode project settings to make sure that no additional stripping takes place.

If something in my builds is incorrect please tell me what to change.

We have just changed the source to use wxMAC_ALWAYS_USE_GENERIC_LISTCTRL on OSX, but I do not have test data yet. I wanted to post this mail to give you feedback on the build route of wxMac 2.8.7

thanks,
Harry

[csomor]

Hi Harry

thanks for supporting me, I'm building currently on Leopard, and slowly getting forwar, I'll get through I hope. The most important part that is not built using debug info is wx itself, because of the --disable-debug configure line in wxmac28.sh.
- The bleeding through is something I hope I can fix for the coregraphics situation, so that this should go away,
- There are instances where you are using 'out-of -order redraws' forced by using a wxClientDC instead of just calling a Refresh() on the window and handling everything in the Paint event with a wxPaintDC, this essentially brings down speed on a platform like OSX that has a more sophisticated but also slower drawing subsystem.
I'll keep you posted

Thanks,

Stefan

[harryvanderwolf]

Replying to csomor:

Hi Harry

The most important part that is not built using debug info is wx itself, because of the --disable-debug configure line in wxmac28.sh.

I know that, I created a new wxmac28-debug.sh script with all the settings is mentioned in my previous post. I know now what my error is. I did not know that when building a debug directory the libs are called libwx_macud* and libwx_macud_gl* in stead of libwx_macu* and libwx_macu_gl*. In my new script I used the old names without the "d". That's why the old non-debug libs were copied in. I've already changed the script and uploaded it to svn (svn 3097). I did rebuild the debug libs and I will build a new Hugin debug version early evening.

[harryvanderwolf]

I said: "I did not know that when building a debug directory"

I meant: "I did not know that when building a debug dylib"

Harry

[harryvanderwolf]

I have problems running the bundle. The building works fine but upon running I get the following error:
Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6).

I have very limited time tonigt. I hope to be able to finish it tomorrow.

Harry

[csomor]

Hi Harry

no problem, I have it running it asserts as expected at a place where it shouldn't ...

the assert triggers in :

wxMacDataItem* wxMacDataItemBrowserControl::GetItemFromLine(unsigned int n) const
{

DataBrowserItemID id;
OSStatus err = GetItemID( (DataBrowserTableViewRowIndex) n , &id);
wxASSERT( err == noErr);
return (wxMacDataItem*) id;

}

but I have no idea yet why suddenly it gets into trouble accessing the same line that just worked seconds before, I still think that we run into some 'overflow' of events,

(the problem you are having is because since you don't use wx-config, you must manually make sure that all code that is now using the wx-debug variant is having WX_DEBUG defined as 1 otherwise you get the mismatch because your code reading the headers doesn't have this set while the library has .. )

Best,

Stefan

[csomor]

sorry Wiki Formatting interfered, the preproc define ist

__WX_DEBUG__

Best,

Stefan

[vadz]

I wouldn't normally correct you but as you started doing it yourself :-) let's get this right: actually it's

__WXDEBUG__

[csomor]

Thanks Vadim, how many ways to get such a simple thing wrong ... :-)
Stefan

[harryvanderwolf]

Replying to csomor:

Hi Harry
.....
(the problem you are having is because since you don't use wx-config, you must manually make sure that all code that is now using the wx-debug variant is having WX_DEBUG defined as 1 otherwise you get the mismatch because your code reading the headers doesn't have this set while the library has .. )

Best,

Stefan

Hi Stefan,
Thanks for the explanation. In which code files do I have to change that. Do I need to change that in "some" wx header file or in all code files that use wx-headers or all code files that use wx-coding or both or ..?
So, is it a massive load of work or just some quick changes?

Hoi,
Harry

[csomor]

Hi

I think I have found the reason :

in hugin you are wiring up two events, the line selected and deselected, to the same handler

EVT_LIST_ITEM_SELECTED(XRCID("cp_list_frame_list"), CPListFrame::OnCPListSelectionChanged)
EVT_LIST_ITEM_DESELECTED(XRCID("cp_list_frame_list"), CPListFrame::OnCPListSelectionChanged)

but in this handler you don't verify which event you are getting, now on mac the selection of the new line is triggered by the OS before the deselection of the old line, and these notifications are queued, and are delivered a split second after the change occured, so

 int itemsSelected = m_list->GetSelectedItemCount();

is always 1, both when the ITEM_SELECTED, and the ITEM_DESELECTED are delivered, now because the only tests whether itemsSelected is 1, and because ITEM_DESELECTED is delivered after ITEM_SELECTED the true state of your images in the pane is always one step behind to the state of the control points list frame, this now poses a problem, eg if in your sample project I first click on line 20 and then on line 19, now the images still show image 0 and 4 with a 4 line list, but the cplistframe wants now to set to control point 19, which doesn't exist in this pair, it is an out-of-bounds which is happening (your debug messages also report this on the console). I'd suggest to change OnCPListSelectionChanged in the if ( 1 == itemsSelected ) branch to make sure we are only dealing with ITEM_SELECTED events, eg by :

    if (1 == itemsSelected) {
        if ( e.GetEventType() == wxEVT_COMMAND_LIST_ITEM_SELECTED ) {
            int cp = m_list->GetItemData(e.GetIndex());
            m_mainFrame->ShowCtrlPoint((unsigned int) cp);
        }
    } else if (0 == itemsSelected) {

Could you please verify whether this solves the problem for you ? Thanks

Stefan

[csomor]

Hi Harry

I really don't know about cmake, you should be able to set the CFLAGS somewhere, so that it is used for all builds, eg just add

-D__WXDEBUG__

to the already existing CFLAGS

HTH

Stefah

[harryvanderwolf]

Hi Stefan,

Thanks for the cflag tip. It's quite easy to add a(nother) CFLAG (-DWXDEBUG) to the Xcode project so I finally succeeded in making a debug bundle.

The bundle uses the "wxMAC_ALWAYS_USE_GENERIC_LISTCTRL" option and is built with your patch as you described above. I did two small tests and it seems to work. The "background selection" of CP's in the images when modifying the CP table still occurs. I will do some further tests tonight and I will ask "our" OSX users to test too.

you can download the bundle from  http://hugin.panotools.org/testing/hugin/DEBUG/3096-DEBUG-wxMAC_ALWAYS_USE_GENERIC_LISTCTRL.dmg.gz
It's again a big boy (63MB compressed and 276 MB uncompressed).

Thanks so far and I hope to get back to you asap.

Harry

[harryvanderwolf]

Hi,

I tested it on a project with 70 2136x2858 images having 2425 Control points, which is really a very big project. I tried to make it crash in all kinds of ways but it keeps running.
I also used it on a 12 images project with 312 Control Points. No crash either.
I already did a couple of small tests on smaller projects. All went well.
I think the issue is solved but I need to wait for other users to test too. A couple reacted and I hope to see their results soon.

You can follow the thread via  http://groups.google.com/group/hugin-ptx/browse_thread/thread/d0b585c67912f57f/d8ec24dd08bf22d4?#d8ec24dd08bf22d4

Hi,
Harry

[csomor]

Hi Harry,

the usage of the generic control itself solves the problem, because there the suite of events is as your original code expected. Of course the native list control would be preferrable, so perhaps you might do another build that does not use the generic control, but has the fix I've outlined.

I'll try to fix the bleeding through also tomorrow, I'll detail then also another suggestion I have for speeding up things a little bit on the redraw side

Best,

Stefan

[harryvanderwolf]

Stefan,

Opening the window for the control point table for the 70 2136x2858 images project having 2425 Control points with "wxMAC_ALWAYS_USE_GENERIC_LISTCTRL" takes about 1-2 seconds (on my macbook). Selecting sets of CP's and deleting them works fine, so working with the control point table is "comfortable" even with such a huge set.

So, to compare I built another version where I disabled the "wxMAC_ALWAYS_USE_GENERIC_LISTCTRL" setting and used the same
70 2136x2858 images project having 2425 Control points. It now takes 3 minutes (!) to open the window of the controlPoint table. Selecting a set of CP's works fine. Deleting these selected CP's also takes approx 3 minutes, which means that it is ahrdly possible to work with the CP table window. However, it didn't crash but I did not push it to the limits as that is simply not possible with such a performance.

Thanks for your help. I'm looking forward to your other "patches".

Harry

[csomor]

Hi Harry

thanks for the feedback, I've meanwhile read the thread on the link you gave me, and I saw you had a problem with list performance as well, could you post some big project somewhere, so that I can profile where time is lost ?

Thanks,

Stefan

[harryvanderwolf]

We have a user who published this set. Have a look at ftp.ds.org (anonymous login) and into the directory hugin. You'll find the 70 images set there.

I put a pto file at  http://panorama.dyndns.org/tmp. It only contains the CP's. No optimization has been done yet.

Harry

[yuv]

 http://www.photopla.net/hugin/big-project.zip, 1GB file, 270 images. gigapixel panorama. been uploading it for the last three hours and it will likely be ready in one hour or so. download speed should be fast, the server has big pipes.

[csomor]

thanks, that's perfect, I've got good download speed as well, so we just hope your upload links stays stable ;-)

Best,

Stefan

[csomor]

Hi

I forgot to tell that I've commited some changes to WX_2_8_BRANCH so that also the wxMAC_USE_CORE_GRAPHICS = 1 case doesn't bleed through from the back tab

Best,

Stefan

[harryvanderwolf]

You mean the CVS/SVN branch here?

And if so, are there more changes compared to the stable 2.8.7 version?

Harry

[csomor]

yes, that's the svn branch WX_2_8_BRANCH, there are more changes, too many to number, most probably are not relevant to hugin, but some are, eg there were some memory leaks in the native listctrl that are fixed now, we are close to releaseing 2.8.8 RC, so I'd think your rather safe to try ...

Best,

Stefan

[csomor]

Hi Harry and Yuv

thanks to you for the samples, that was what I needed :-) after this morning the download speed for yuv's archive was close to zero, this afternoon I reached an average of 370 KB/s so I could test against this as well.

I've done the following : WX_2_8_BRANCH now supports Freeze and Thaw for the native list control
for this to have a noticable effect you have to add Freeze/Thaw also in CPListFrame.cpp :

void CPListFrame::panoramaImagesChanged(PT::Panorama &pano, const PT::UIntSet & imgNr)
{
    DEBUG_TRACE("");
    const CPVector & cpv = pano.getCtrlPoints();
    unsigned int nrCP = cpv.size();
    unsigned int nrItems = m_list->GetItemCount();
    DEBUG_TRACE("nr CP:" << nrCP << " nr listentries:" << nrItems);

    m_list->Freeze(); // <-- this line added by CS
//    m_list->Hide();


 ....

    m_list->Thaw(); // <--- this line added by CS
}

Best Regards,

Stefan

[harryvanderwolf]

Hi Stefan,

Thanks for your work. The changes you describe here for 2.8.8 RC version, are they generic? e.g. for wxMac, windows and linuxes?
I would like to use it, but I would like to know whether I have to use some statement like :
#ifdef wxMAC

"New Code"

#endif

as Hugin is a multi-platform application.

Harry

[csomor]

Hi Harry

these changes are crossplatform, no #ifdef necessary in your code

Best,

Stefan

[harryvanderwolf]

I did build the i386 library 2.9.0.0.0, but I can't build the ppc library. As it might or might not be related to this topic I copied the error in the mail below.
However, when trying to build a i386 hugin with wxmac 2.9 I do get quite some errors. As I'm not a developer I can't judge them well enough but I think the hugin code is maybe "too strict" with regard to wxwidgets. I have to discus this with the main developer. As we are currently aiming for a new 0.7 "MileStone" release of Hugin, I'm afraid this might take some time until the 0.7.1 version, as we are now in the "bug fixing phase" before next build

I'll try to give you feedback as soon as possible.

Harry

(error of ppc build of 2.9.0)

(pc-build/lib/wx/include/mac-unicode-release-2.9 -I../include -fpascal-strings -I../src/mac/carbon/morefilex -I/Developer/Headers/FlatCarbon -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include -DWX_PRECOMP -O2 -fno-strict-aliasing -arch ppc -mcpu=G3 -mtune=G4 -mmacosx-version-min=10.3 -O2 -dead_strip -fno-common -fvisibility=hidden -fvisibility-inlines-hidden ../src/common/filefn.cpp
../include/wx/mac/carbon/dcclient.h:26: error: expected class-name before '{' token
make: *** [monodll_filefn.o] Error 1)

[csomor]

Hi Harry

please don't use TRUNK a.k.a 2.9 use the stable WX_2_8_BRANCH, which is much more stable and will become 2.8.8 shortly

Best,

Stefan

[harryvanderwolf]

Hi Stefan,

Please explain. I did find the 2.8.8-rc1 (in  http://biolpc22.york.ac.uk/pub/2.8.8-rc1/) but the latest, not even mac, was from May 23, so I expected that your changes of 29/30/31 May were not in. That's why I assumed that I had to take "the latest" CVS/SVN trunk, which turned out to be 2.9. (btw: was the server down during the weekend?).
Where do I find this stable 2.8.8 branch with your patches, do you have a link?

kind regards,
Harry

[csomor]

Hi Harry

(for more details see  http://www.wxwidgets.org/develop/svn.htm

to check-out WX_2_8_BRANCH from svn on mac, open Terminal

svn checkout http://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_2_8_BRANCH wxWidgets-2.8

HTH

Stefan

[harryvanderwolf]

Hi Stefan,

Sorry for this rather late feedback. I did find the 2.8.8 svn after your hint (but again, when having such a big "Download now" link on the home page, I expect that "everything" is behind that link (be it under "other downloads").

One point is that I have two development trees. One completely separated within the hugin tree for the bundle and one spread over /opt/local (macports) and /usr/local (the "linux" way) for the command line version and other projects I'm working on. All libs are universal

The second route:
Some libraries can be compiled with macports, some need to be compiled by hand in two steps. The second route did not allow me to compile (bot the i386 and ppc version) without specifiying --with-expat=builtin --with-libpng=builtin as wxwidgets could not find them (they are in /opt/local). I specified the settings:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/local/lib/pkgconfig
export CFLAGS="-I/opt/local/include -I/usr/local/include -L/opt/local/lib -L/usr/local/lib"
export CXXFLAGS=$CFLAGS
Complete configure line: ../configure --disable-debug --enable-monolithic --enable-unicode --with-opengl --enable-compat26 --disable-graphics_ctx --enable-shared --with-mac --with-expat=builtin -with-libpng-builtin;

and for PPC:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/local/lib/pkgconfig
export CFLAGS="-I/opt/local/include -I/usr/local/include -L/opt/local/lib -L/usr/local/lib -arch ppc"
export CXXFLAGS=$CFLAGS
../configure CPPFLAGS="-arch ppc" LDFLAGS="-arch ppc" CC="gcc -arch ppc" --disable-debug --enable-monolithic --enable-unicode --with-opengl --enable-compat26 --disable-graphics_ctx --enable-shared --with-mac --with-expat=builtin --with-libpng=builtin

First route (within hugin tree for Xcode bundle build):
i386 compiles fine. For the ppc version I get the following error:
-mmacosx-version-min=10.3 -O2 -dead_strip -fno-common ../src/mac/common/glgrab.c
../src/mac/common/glgrab.c: In function 'grabViaOpenGL':
../src/mac/common/glgrab.c:112: error: 'kCGColorSpaceGenericRGB' undeclared (first use in this function)
../src/mac/common/glgrab.c:112: error: (Each undeclared identifier is reported only once
../src/mac/common/glgrab.c:112: error: for each function it appears in.)
../src/mac/common/glgrab.c:199: warning: implicit declaration of function 'CGBitmapContextCreateImage'
../src/mac/common/glgrab.c:199: warning: assignment makes pointer from integer without a cast
make: *** [monodll_glgrab.o] Error 1

Does this ring a bell?

I just realized that I hadn't thanked you for your help so far. I really appreciate your help and the amount of time you put into this. Thanks a lot.

Harry

[csomor]

Hi Harry

there are downloads - which are releases, and the state between releases - in svn. 2.8.8 isn't out yet, there will be the usual RC.. downloads soon, but before that svn is the only way to get the 'bleeding edge'.

thanks for pointing out this problem with glgrab, yes, apparently we have a 10.4 dependancy there, I've replaced that with a separate method I needed for the same constant at another point in the code, committed to WX_2_8_BRANCH (do a svn update in the toplevel wx dir)

Best,

Stefan

[harryvanderwolf]

Hi Stefan,

Sorry to be back with another error. I synced with svn. I'm now running into the following error (for ppc):

g++ -isysroot /Developer/SDKs/MacOSX10.3.9.sdk -c -o monodll_renderer.o -I.pch/wxprec_monodll -DWXMAC -I../src/regex -DwxUSE_BASE=1 -DWXMAKINGDLL -dynamic -fPIC -DPIC -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/wxWidgets-2.8/osx-ppc-build/lib/wx/include/mac-unicode-release-2.8 -I../include -fpascal-strings -I../src/mac/carbon/morefilex -I/Developer/Headers/FlatCarbon -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include -DWX_PRECOMP -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -arch ppc -mcpu=G3 -mtune=G4 -mmacosx-version-min=10.3 -O2 -dead_strip -fno-common ../src/mac/carbon/renderer.cpp
../src/mac/carbon/renderer.cpp: In member function 'virtual void wxRendererMac::DrawCheckBox(wxWindow*, wxDC&, const wxRect&, int)':
../src/mac/carbon/renderer.cpp:513: error: 'kThemeCheckBoxSmall' was not declared in this scope
../src/mac/carbon/renderer.cpp:516: error: 'kThemeCheckBoxMini' was not declared in this scope
../src/mac/carbon/renderer.cpp: In function 'void wxRenderer_DrawRadioButton(wxWindow*, wxDC&, const wxRect&, int)':
../src/mac/carbon/renderer.cpp:614: error: 'kThemeRadioButtonSmall' was not declared in this scope
../src/mac/carbon/renderer.cpp:617: error: 'kThemeRadioButtonMini' was not declared in this scope
make: *** [monodll_renderer.o] Error 1

Harry

[csomor]

Hi Harry

could you change --with-macosx-sdk=/Developer/SDKs/MacOSX10.3.9.sdk to --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk also for the ppc target, since you are indicating with -mmacosx-version-min=10.3 that it must run under 10.3.9 as well, this should keep your build running ok

Best,

Stefan

[harryvanderwolf]

I compiled the ppc version with the --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk

Now it compiles and links fine.
Does this mean that 10.3.9 is no longer supported as of 2.8.8?

Hi,
Harry

[csomor]

it is supported for running (that's what you indicate with the -mmacosx-version-min) but I'll need to have a look at whether we still can easily support compiling against 10.3.9. It is reasonable to compile against the 10.4 sdk so that certain features that only exist in the newer systems are used, these are never compiled in if you only build against a 10.3.9 sdk, so for your app I'd switch that anway, but I'll try to keep it working ..

Best,

Stefan

[harryvanderwolf]

Well,

I can off course ask our community how many users are still on 10.3.9, as I have really no idea.

As I'm not a developer this could be a really silly question, but is it easy to make -disable-feature configure switch for "old" systems?
I then would by default make the svn builds for 10.4.x and up and "milestone" builds for 10.4.x and up and for 10.3.9 and up with the --disable-feature switch to stay backward compatible.

You now have the compatibility switches for 2.4 and 2.6, than this would be an "incompatibility" switch.

I forgot to mention that the bleeding through is solved now for Intel. I have to ask other users on ppc (with 10.4) to test that as I don't want to build solely ppc on my intel.

bye,
Harry

[csomor]

Hi Harry

I've probably not explained correctly, you can build against a 10.4 SDK but still have that application run smoothly on 10.3.9, you are doing this by definining the -mmacosx-version-min=10.3, that's what you already do, so this change only involves people that BUILD hugin. There's nothing you have to do, I check at runtime whether the method I want to call is already present on the system I'm running on, and if it is not, I'm using an older method.

In the meantime I've fixed the compile problems also for 10.3, so you can build again as you did before, but I'd really recommend building against 10.4.SDK also on ppc, so that those users who are on ppc but are running on Tiger can benefit from code written for these newer systems while not leaving 10.3.9 behind.

Best,

Stefan

[harryvanderwolf]

Hi Stefan,

PPC compilation with 10.4 compiles allright. If I compile ppc with the 10.3.9 SDK I get the following error:

_DataBrowserChangeAttributes referenced from libwx expected to be defined in Carbon
_PMGetDuplex referenced from libwx expected to be defined in Carbon
_PMSetDuplex referenced from libwx expected to be defined in Carbon
_TXNGetCommandEventSupport referenced from libwx expected to be defined in Carbon
_TXNSetCommandEventSupport referenced from libwx expected to be defined in Carbon
_TXNSetSpellCheckAsYouType referenced from libwx expected to be defined in Carbon
/usr/bin/libtool: internal link edit command failed
make: *** /Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/wxWidgets-2.8/osx-ppc-build/lib/libwx_macu_gl-2.8.0.5.0.dylib Error 1
mv: /Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/ ppc/lib/wx/include/mac-unicode-r

For some reason I had to recompile lib expat to be able to compile i386 after your latest changes (enabling 10.3.9 again). Still the same expat version (expat-2.0.1) and identical compilation, but still necessary.

Also: The developer who did the scripting for the libs entered the following in the build script:
# # disable core graphics implementation for 10.3

if [[ $TARGET == *darwin7 ]]
then

echo '#ifndef wxMAC_USE_CORE_GRAPHICS' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo ' #define wxMAC_USE_CORE_GRAPHICS 0' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo '#endif' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h

fi

Is this still necessary after your changes?
Is it necessary only for the 10.3.9SDK and not for the 10.4u.SDK?

Are you really sure that I can compile for 10.3 with the 10.4 SDK? Why is the 10.3.9SDK than still there? As far as I understood the 10.4u.SDK is for ppc and intel as of 10.4, and the 10.3.9SDK for ppc below 10.4. I did search developer.apple.com but can't find a real statement or table displaying supported OS levels.

Harry

[pablo]

Hi Stefan,

As the guy who has written most of the hugin code, I'm very impressed that you went though the hassle to find the bugs in hugin. Thank you a lot!

- The bleeding through is something I hope I can fix for the coregraphics situation, so that this should go away,

- There are instances where you are using 'out-of -order redraws' forced by using a wxClientDC instead of just calling a Refresh() on the window and handling everything in the Paint event with a wxPaintDC, this essentially brings down speed on a platform like OSX that has a more sophisticated but also slower drawing subsystem.
I'll keep you posted

I have replaced the 2 out of order redraws in hugin with Refresh(). Will this also help with the bleeding through?

If you stumbled across some other strange or inefficient wxWidgets usage in hugin, just let me know, I'll try to fix it!
Actually, I have a question with about how to receive updates from wxTextCtrl, as I'm currently using a "hack" that converts EVT_KILL_FOCUS events to wxEVT_COMMAND_TEXT_ENTER, to avoid updating/redrawing the whole application status (expensive) on every single key press. This seems to work fine on wxGTK and wxMSW, but not so well on OSX, as the kill focus events seems to be delayed there. Specifically, entering a JPEG compression factor into the wxTextCtrl on the "Panorama tab" and then clicking on the "Stitch now!" button doesn't trigger a EVT_KILL_FOCUS event for the wxTextCtrl.

Should I create a separate bug for this?

Thanks,

Pablo

[csomor]

Replying to harryvanderwolf:

Hi Stefan,

PPC compilation with 10.4 compiles allright. If I compile ppc with the 10.3.9 SDK I get the following error:

_DataBrowserChangeAttributes referenced from libwx expected to be defined in Carbon
_PMGetDuplex referenced from libwx expected to be defined in Carbon
_PMSetDuplex referenced from libwx expected to be defined in Carbon
_TXNGetCommandEventSupport referenced from libwx expected to be defined in Carbon
_TXNSetCommandEventSupport referenced from libwx expected to be defined in Carbon
_TXNSetSpellCheckAsYouType referenced from libwx expected to be defined in Carbon
/usr/bin/libtool: internal link edit command failed

this looks to me like some mixup of preproc constants, please do a clean rebuild, as eg DataBrowserChangeAttributes is guarded with a check so that this code line is only compiled if

#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4

and this only is the case (as far as I can imagine) if 10.4 SDK is pulled in

Also: The developer who did the scripting for the libs entered the following in the build script:
# # disable core graphics implementation for 10.3
if [[ $TARGET == *darwin7 ]]
then
echo '#ifndef wxMAC_USE_CORE_GRAPHICS' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo ' #define wxMAC_USE_CORE_GRAPHICS 0' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo '#endif' >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
echo >> lib/wx/include/mac-unicode-release-$WXVERSION/wx/setup.h
fi

Is this still necessary after your changes?
Is it necessary only for the 10.3.9SDK and not for the 10.4u.SDK?

that's a valid point still, Ippei once wrote to me because of the invert ROP which I cannot deliver unless running on 10.4 in core-graphics mode, therefore that's still valid, as long as the resulting binary should be able to run on 10.3.9

Are you really sure that I can compile for 10.3 with the 10.4 SDK? Why is the 10.3.9SDK than still there? As far as I understood the 10.4u.SDK is for ppc and intel as of 10.4, and the 10.3.9SDK for ppc below 10.4. I did search developer.apple.com but can't find a real statement or table displaying supported OS levels.

the 10.3.9.SDK gives you the option to check that your code is not pulling in a method unguarded that doesn't exist on a system, there maybe other backwards compatibility reasons I don't remember about. 10.4.u.sdk can be used for 10.3 apps ppc, if you are using gcc 4.0 then it's only for 10.3.9 and upper, if you are using gcc 3.3 you can go lower on 10.3, for more inspirational (but longer ;-) reading:

 http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html

Best,

Stefan

[csomor]

Hi Pablo

Replying to pablo:

Hi Stefan,

As the guy who has written most of the hugin code, I'm very impressed that you went though the hassle to find the bugs in hugin. Thank you a lot!

you are very welcome

- The bleeding through is something I hope I can fix for the coregraphics situation, so that this should go away,

- There are instances where you are using 'out-of -order redraws' forced by using a wxClientDC instead of just calling a Refresh() on the window and handling everything in the Paint event with a wxPaintDC, this essentially brings down speed on a platform like OSX that has a more sophisticated but also slower drawing subsystem.
I'll keep you posted

I have replaced the 2 out of order redraws in hugin with Refresh(). Will this also help with the bleeding through?

the bleading through should be solved by my other fixes (please repost if still persistent), the issue with wxClientDC is that in core graphics its code is rather heavy from what's happening behind, also potentially blocking if issued to frequently, so getting rid of wxClientDC except for eg measuring is very much recommended

If you stumbled across some other strange or inefficient wxWidgets usage in hugin, just let me know, I'll try to fix it!
Actually, I have a question with about how to receive updates from wxTextCtrl, as I'm currently using a "hack" that converts EVT_KILL_FOCUS events to wxEVT_COMMAND_TEXT_ENTER, to avoid updating/redrawing the whole application status (expensive) on every single key press. This seems to work fine on wxGTK and wxMSW, but not so well on OSX, as the kill focus events seems to be delayed there. Specifically, entering a JPEG compression factor into the wxTextCtrl on the "Panorama tab" and then clicking on the "Stitch now!" button doesn't trigger a EVT_KILL_FOCUS event for the wxTextCtrl.

Should I create a separate bug for this?

I'm sorry, but as I understand the operation from your description, this behaviour is not a bug, but a platform difference. Unless operated in "full keyboard access mode" on OSX a button does not get the focus, therefore the textctrl keeps the keyboard focus and does not issue a kill-focus. Did you consider using a idle event handler for these kind of updates ?

Best,

Stefan