Core-dump pasting from one form field into another
Hello All, This is exercisable in Dillo 3.0.4.1, but not new. I found it by accident in my hack-up of Dillo 3.0.4. The reproduction is: - enable cookies for .google.com - navigate to https://mail.google.com/mail/?ui=html - fight the links until you get a screen with two fields, one for the username and one for the password - type something into the username field - select it and drag to the password field -- core dump I am on: - OSX 10.6.8 - Dillo 3.0.4.1 with SSL enabled - FLTK 1.3.3 - with dpid, etc from Dillo 3.0.4 with extensive hacking so the fault could be Mac-specific. Essentially the same fault (in Fl::dnd()) is reproducible in clean Dillo 3.0.4, with FLTK 1.3.2, clean dpid, etc, so I *think* it's not a product of my hackery. Clean Dillo 3.0.4 does not report the CGContextSetShouldAntialias and related errors, so I *think* that they are unrelated. Some errors and backtrace below. So far, I have not reproduced this fault in the FLTK input test program. Does anyone have a favourite piece of form html for me to try, to see if we can get out of needing gmail for the reproduction. Regards, James. ======================== Sat Dec 27 12:16:00 James-MacBook.local dillo[93125] <Error>: CGContextSetShouldAntialias: invalid context 0x0 Sat Dec 27 12:16:00 James-MacBook.local dillo[93125] <Error>: CGContextSetTextPosition: invalid context 0x0 Sat Dec 27 12:16:00 James-MacBook.local dillo[93125] <Error>: CGContextSetShouldAntialias: invalid context 0x0 Sat Dec 27 12:16:00 James-MacBook.local dillo[93125] <Error>: CGContextSetShouldAntialias: invalid context 0x0 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x00007fff8a1cd7cd in __dynamic_cast () (gdb) bt #0 0x00007fff8a1cd7cd in __dynamic_cast () #1 0x000000010009b318 in Fl::dnd () at Fl_cocoa.mm:3792 #2 0x00000001000aee3f in Fl_Input::handle (this=<value temporarily unavailable, due to optimizations>, event=<value temporarily unavailable, due to optimizations>) at Fl_Input.cxx:681 #3 0x0000000100071187 in CustInput2::handle (this=0x103c10a00, e=5) at fltkui.cc:86 #4 0x000000010009cfda in send (event=<value temporarily unavailable, due to optimizations>, to=<value temporarily unavailable, due to optimizations>, window=<value temporarily unavailable, due to optimizations>) at Fl.cxx:1143 #5 0x000000010009eaf7 in Fl::handle_ (e=5, window=0x102a1e020) at Fl.cxx:1455 #6 0x000000010009ad28 in cocoaMouseHandler (theEvent=0x100565980) at Fl_cocoa.mm:1057 #7 0x00007fff890580c7 in -[NSWindow sendEvent:] () #8 0x00007fff88f8cafa in -[NSApplication sendEvent:] () #9 0x000000010009af43 in +[FLApplication sendEvent:] (self=<value temporarily unavailable, due to optimizations>, _cmd=<value temporarily unavailable, due to optimizations>, theEvent=0x100565980) at Fl_cocoa.mm:1453 #10 0x000000010009883a in do_queued_events (time=1e+20) at Fl_cocoa.mm:772 #11 0x000000010009b175 in fl_wait [inlined] () at /Users/jamescone/buildTrees/fltk/fltk-1.3.3/src/Fl_cocoa.mm:796 #12 0x000000010009b175 in fl_mac_flush_and_wait (time_to_wait=1e+20) at Fl_cocoa.mm:815 #13 0x000000010009df39 in Fl::run () at Fl.cxx:589 #14 0x0000000100004819 in main (argc=1, argv=0x7fff5fbff3f0) at dillo.cc:572 (gdb)
James wrote:
This is exercisable in Dillo 3.0.4.1, but not new. I found it by accident in my hack-up of Dillo 3.0.4.
The reproduction is: - enable cookies for .google.com - navigate to https://mail.google.com/mail/?ui=html - fight the links until you get a screen with two fields, one for the username and one for the password - type something into the username field - select it and drag to the password field -- core dump
I am on:
- OSX 10.6.8 - Dillo 3.0.4.1 with SSL enabled - FLTK 1.3.3 - with dpid, etc from Dillo 3.0.4 with extensive hacking
so the fault could be Mac-specific.
I tried playing around a little, on linux and not having a gmail acct, and nothing wanted to go wrong, so, yeah, it might be an osx issue...
On Sat, Dec 27, 2014 at 06:22:12PM +0000, eocene wrote:
James wrote:
This is exercisable in Dillo 3.0.4.1, but not new. I found it by accident in my hack-up of Dillo 3.0.4.
The reproduction is: - enable cookies for .google.com - navigate to https://mail.google.com/mail/?ui=html - fight the links until you get a screen with two fields, one for the username and one for the password - type something into the username field - select it and drag to the password field -- core dump
I am on:
- OSX 10.6.8 - Dillo 3.0.4.1 with SSL enabled - FLTK 1.3.3 - with dpid, etc from Dillo 3.0.4 with extensive hacking
so the fault could be Mac-specific.
I tried playing around a little, on linux and not having a gmail acct, and nothing wanted to go wrong, so, yeah, it might be an osx issue...
Can't reproduce it either on DragonFly BSD. I can try later to get a stack trace on osx. Cheers, Johannes
On Sat, Dec 27, 2014 at 08:42:55PM +0100, Johannes Hofmann wrote:
On Sat, Dec 27, 2014 at 06:22:12PM +0000, eocene wrote:
James wrote:
This is exercisable in Dillo 3.0.4.1, but not new. I found it by accident in my hack-up of Dillo 3.0.4.
The reproduction is: - enable cookies for .google.com - navigate to https://mail.google.com/mail/?ui=html - fight the links until you get a screen with two fields, one for the username and one for the password - type something into the username field - select it and drag to the password field -- core dump
I am on:
- OSX 10.6.8 - Dillo 3.0.4.1 with SSL enabled - FLTK 1.3.3 - with dpid, etc from Dillo 3.0.4 with extensive hacking
so the fault could be Mac-specific.
I tried playing around a little, on linux and not having a gmail acct, and nothing wanted to go wrong, so, yeah, it might be an osx issue...
Can't reproduce it either on DragonFly BSD. I can try later to get a stack trace on osx.
On MacOSX all attempts to drag and drop crash dillo for me. As it also causes confusion on X11 based systems I disabled DND alltogether for now. Cheers, Johannes
Hi All, I think I've worked out what's going on with drag-and-drop. We're compiling with -fno-rtti and (some parts of) fltk do dynamic_cast, which needs rtti. The run-time handling for detecting the conflict is nonexistent/unforgiving. When I make the change below and rebuild, drag-and-drop starts working for me. The executable size penalty is significant. The only 3+MB one is the only one with rtti turned on: ...$ ls -l versions/*/*/src/dillo -rwxr-xr-x 1 ... staff 2943392 25 Nov 21:42 versions/cookies/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 3253032 20 Jan 20:10 versions/everything/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2943096 26 Oct 16:46 versions/pull-everything/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2942840 15 Sep 18:11 versions/render/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2942448 28 Oct 17:58 versions/ssh-everything-dirty/dillo-jfw01/src/dillo ...$ There are two dynamic casts in fltk: ./src/Fl_cocoa.mm:3792: if ( dynamic_cast<Fl_Input_*>(w) != NULL || dynamic_cast<Fl_Text_Display*>(w) != NULL) { ./src/Fl_cocoa.mm:3973: BOOL to_quartz = dynamic_cast<Fl_Printer*>(this) != NULL; I have no opinion yet about how difficult they would be to replace. The way forward should be decided by someone who remembers why no-rtti was originally turned on. Regards, James. $ hg diff configure.ac diff -r e773dab661ec configure.ac --- a/configure.ac Wed Sep 17 00:24:37 2014 +1200 +++ b/configure.ac Tue Jan 20 20:49:00 2015 +1300 @@ -488,7 +488,8 @@ dnl if eval "test x$GCC = xyes"; then - CXXFLAGS="$CXXFLAGS -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions" + CXXFLAGS="$CXXFLAGS -Wall -W -Wno-unused-parameter -fno-exceptions" +dnl removed -fno-rtti to enable DND in FLTK fi AC_SUBST(BASE_CUR_WORKING_DIR) On 1/7/15, Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
On Sat, Dec 27, 2014 at 08:42:55PM +0100, Johannes Hofmann wrote:
On Sat, Dec 27, 2014 at 06:22:12PM +0000, eocene wrote:
James wrote:
This is exercisable in Dillo 3.0.4.1, but not new. I found it by accident in my hack-up of Dillo 3.0.4.
The reproduction is: - enable cookies for .google.com - navigate to https://mail.google.com/mail/?ui=html - fight the links until you get a screen with two fields, one for the username and one for the password - type something into the username field - select it and drag to the password field -- core dump
I am on:
- OSX 10.6.8 - Dillo 3.0.4.1 with SSL enabled - FLTK 1.3.3 - with dpid, etc from Dillo 3.0.4 with extensive hacking
so the fault could be Mac-specific.
I tried playing around a little, on linux and not having a gmail acct, and nothing wanted to go wrong, so, yeah, it might be an osx issue...
Can't reproduce it either on DragonFly BSD. I can try later to get a stack trace on osx.
On MacOSX all attempts to drag and drop crash dillo for me. As it also causes confusion on X11 based systems I disabled DND alltogether for now.
Cheers, Johannes
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
Hi James, On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote:
Hi All,
I think I've worked out what's going on with drag-and-drop.
We're compiling with -fno-rtti and (some parts of) fltk do dynamic_cast, which needs rtti. The run-time handling for detecting the conflict is nonexistent/unforgiving.
When I make the change below and rebuild, drag-and-drop starts working for me.
Cool that you found the reason!
From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work without rtti, but things might have changed of course. It would be cool if you could bring up the topic on an fltk list to see if it's intended like this.
Cheers, Johannes
Hello Johannes et al, I've logged this with the FLTK people. http://www.fltk.org/str.php?L3178 Regards, James. On 20/01/2015, Johannes Hofmann <johannes.hofmann at gmx.de> wrote:
Hi James,
On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote:
Hi All,
I think I've worked out what's going on with drag-and-drop.
We're compiling with -fno-rtti and (some parts of) fltk do dynamic_cast, which needs rtti. The run-time handling for detecting the conflict is nonexistent/unforgiving.
When I make the change below and rebuild, drag-and-drop starts working for me.
Cool that you found the reason! From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work without rtti, but things might have changed of course. It would be cool if you could bring up the topic on an fltk list to see if it's intended like this.
Cheers, Johannes
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
Hello Johannes et al, Unless circumstances intervene, a future release of FLTK will support DND on OSX without RTTI:: https://groups.google.com/forum/#!searchin/fltkgeneral/rtti/fltkgeneral/yxjv... I vote for leaving DND disabled until the FLTK people are ready to make that release. Regards, James. On 23/01/2015, James C <james.from.wellington at gmail.com> wrote:
Hello Johannes et al,
I've logged this with the FLTK people. http://www.fltk.org/str.php?L3178
Regards, James.
On 20/01/2015, Johannes Hofmann <johannes.hofmann at gmx.de> wrote:
Hi James,
On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote:
Hi All,
I think I've worked out what's going on with drag-and-drop.
We're compiling with -fno-rtti and (some parts of) fltk do dynamic_cast, which needs rtti. The run-time handling for detecting the conflict is nonexistent/unforgiving.
When I make the change below and rebuild, drag-and-drop starts working for me.
Cool that you found the reason! From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work without rtti, but things might have changed of course. It would be cool if you could bring up the topic on an fltk list to see if it's intended like this.
Cheers, Johannes
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
Hi James, On Sun, Feb 01, 2015 at 04:06:01PM +1300, James C wrote:
Hello Johannes et al,
Unless circumstances intervene, a future release of FLTK will support DND on OSX without RTTI:: https://groups.google.com/forum/#!searchin/fltkgeneral/rtti/fltkgeneral/yxjv...
thanks that you brought up the topic on the FLTK list!
I vote for leaving DND disabled until the FLTK people are ready to make that release.
sure. Regards, Johannes
Regards, James.
On 23/01/2015, James C <james.from.wellington at gmail.com> wrote:
Hello Johannes et al,
I've logged this with the FLTK people. http://www.fltk.org/str.php?L3178
Regards, James.
On 20/01/2015, Johannes Hofmann <johannes.hofmann at gmx.de> wrote:
Hi James,
On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote:
Hi All,
I think I've worked out what's going on with drag-and-drop.
We're compiling with -fno-rtti and (some parts of) fltk do dynamic_cast, which needs rtti. The run-time handling for detecting the conflict is nonexistent/unforgiving.
When I make the change below and rebuild, drag-and-drop starts working for me.
Cool that you found the reason! From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work without rtti, but things might have changed of course. It would be cool if you could bring up the topic on an fltk list to see if it's intended like this.
Cheers, Johannes
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
participants (4)
-
eocene＠gmx.com -
james.from.wellington＠gmail.com -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de