- Dillo-dev - lists.mailman3.com

Secure: yes, Though Features Missing; and Bugs
by miroslav.rovis1＠zg.ht.hr April 3, 2015

April 3, 2015

Hi! To me it is most important to avail myself of the security that dillo pretty much provides to me. What I can say, and recommend to anybody who has problems with `bulk collection' that they see in typical kind of actions deployed inside or on the way to, or on the way from, their machines... Sadly with `bulk collection' (previously known as `mass surveillance'; it comprises data harvesting and more) often go even worse kind of actions in privacy-repressive regimes: intrusions, even attacks... What I can say, is: I have so much fewer cases of the aforementioned issues when browsing with dillo, then I do when I have to, due to Javascript haven't yet been implemented in dillo, [than when I have to] use SchmoogleFox. So much fewer of those kind of problems! And yes, the Google, the Octopus of the Internet and the Surveillance Engine of the World, yes the Schmoog is sitting in the Firefox, in most of the regular users' machines who little depart from default configuration, and I don't think Mozilla harvesting itself can be easily disabled (you may remove direct Google harvesting/spying/other, but the Mozilla cloud is there, rest assured, for Google to use, fully!), and you can not, not that I know of an easy way --disprove me somebody!-- easily disable harvesting in Firefox... The security of dillo is generally such that I can usually rest calmly when I browse with dillo. And so I can recommend dillo to anybody who has problems with censorship, and when censorship of an oppressive regime is revealed, usually some kind of intrusion attempts, and/or attacks, are made against the one who managed to reveal it. To see more in depth about this claim of mine, read about dillo in the topics where I mention it on Gentoo Forums (just search for `dillo'): Updating and keeping your Gentoo non-poetterized https://forums.gentoo.org/viewtopic-t-1012022-start-0.html (currently three pages, dillo mentioned in 1st and 2nd. Before I close this first message, I'd like to show you this page where I demonstrated not just how the first Firefox harvest looks like on a Chinese style censorship deployed on dissenters in Croatia (that part is already posted: Google - can not open any link - malware ?? https://forums.gentoo.org/viewtopic-t-912056-start-25.html#7715646 but that topic I plan to improve adn add more content to yet) You can see that while I'm not really a programmer, I dabble with some ideas. This is my proposal for a program: https://github.com/miroR/uncenz I've been having censorship and related issues for really quite a number of years, By this current stage in my necessity-imposed research about it, I'm just about always traffic capturing when online, and you can find real and undeniable clickjacking and other intrusions (and learn about the Chinese style censorship and more; but, WARNING, the presentation is not so well made, and is unfinished) at: Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion https://forums.gentoo.org/viewtopic-t-999436.html I believe that an objective reader, with a little time to read from my research there, can see that my praising of dillo is based on my sufficient understanding and experience. I really wish that you dillo developers may gather enough developer power to make dillo happen in the sooner rather than later future, much more capable than it already is. I can imagine what tremendous work creating and developing of a browser is! With that aim and wish in mind, I'd like to write and send another message about another buggish behavior in dillo. But in this message I can explain more about what I wrote on page 2nd of the topic already mentioned: Updating and keeping your Gentoo non-poetterized: https://forums.gentoo.org/viewtopic-t-1012022-start-25.html#7713858 > Other then one thing. dillo, which I used, has a little problem with > cache, that can be easily circumvented, but the user needs to remember > to refresh the page, and I inadvertently lost a little text... The above behavior occurs sometimes on my system, it occurs rather erratically, but rather often, when posting on Gentoo Forums. Not when posting a completely new post, but after editing an already existing post. It is easy to circumvent it, by simply, after having posted the previously edited post in question, refreshing the page which the post appears in. You can often see text literally changing upon refreshing it. The bug often occurs `in reverse', concerning posting. What I mean, is if you open a post for at least the third time --yes it must be a problem related to dillo caching; I understand so much even though I'm not a programmer, but just an advanced user-- so [if you open a post for the third time for editing], unless you refresh the editing texarea, in the same fashion: by clicking on the "Reload" button, you miight find yourself inadvertently to be editing the text that you posted the time before last, and not the immediately previous edit to this third edit of that text (even though the last text, the immediately previous, has, obviously, also been already committed, and should have been shown to you). The other bug, or is it my misconfiguration, or is it something else, I will try and write about in my next post. I sure will try and prepare the next message sson, and send it in a matter of hours or maximally a day or two. But if it does not arrive, the likelihood is that it is waiting for spies at my providers' to read it, and decide whether to send it on, or filter it out and not send it to dillo mailing list at all. Should the latter happen, pls. find that message at not much later time than maximally a day or two from now, in the topic Google - can not open any link - malware ?? https://forums.gentoo.org/viewtopic-t-912056-start-25.html surely, as a new post (which will, in that case, be yet to be written and posted there), and share the link with others on this list, please). (This note NOT related to dillo: Censorship is really a hard issue to overcome. Have a look at: Recover partly overwritten luks volume? https://forums.gentoo.org/viewtopic-t-1004014.html#7724054 --even though I praised dillo in that topic too-- nobody helped me there!) -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

3 4

unicode combining chars and PRE
by eocene＠gmx.com April 3, 2015

April 3, 2015

Looking at http://doc.rust-lang.org/1.0.0-beta/book/more-strings.html#indexing-strings and I see that dillo doesn't like combining characters in PRE. Small example attached.

1 0

Documentation fixes
by onepoint＠starurchin.org March 12, 2015

March 12, 2015

I have four documentation patches ready for review that came from looking at the doxygen error output. The first is the upgrade to Doxyfile, the other three are small fixes to errors that doxygen happened to notice. I hope the extended descriptions will make everything clear. http://starurchin.org/dillo/patch/doxygen-upgrade-config.html http://starurchin.org/dillo/patch/doxygen-remove-unmatched-close-div.html http://starurchin.org/dillo/patch/doxygen-typo-nsbp-entity.html http://starurchin.org/dillo/patch/doxygen-escape-button-tag-angle-brackets.… There is more to do but I'd like to clear these out of the way first. All comments are welcome. Regards, Jeremy Henty

3 3

Problem with page positioning.
by johnfound＠asm32.info March 6, 2015

March 6, 2015

Hi all. It is my first post on this mailing list. I want to use Dillo as a HTML help browser for my program. I need it, because it has faster startup time and this is very important for a help system, where the user presses F1 and expects the help to open instantly. (What is not the case with all other browsers). Anyway, the problem I have is that when starting Dillo with URL that contains local anchor ID, it first positions properly, but short time later, (when the CSS get loaded?) it repositions the page and the needed element moves somewhere else, very far from the current page position. Example that can be tested: http://fresh.flatassembler.net/index.cgi?page=content/articles/2_FreshLibDo… Once the page is loaded (on the wrong position), pressing Ctrl+R or clicking on "Reload" button, repositions the page to the proper position. Is this problem can be easily solved? I can try to fix it by myself, but my C/C++ skills are very low and then I will need some assistance. Best Regards and thanks for the great browser. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

5 11

Dillo documentation delivered daily
by onepoint＠starurchin.org March 4, 2015

March 4, 2015

My website is up again[1] and I have added a daily build of the Dillo documentation (having noticed that the version on the Dillo site is over a year old). HTML: http://starurchin.org/dillo/doc/html/index.html tarball: http://starurchin.org/dillo/doc/dillo-doc.tar.gz (Note that the tarball has moved from its old location.) Doxygen generates quite a few errors when building the docs. I would like to fix them (if only to have less noise from my cron jobs). Would the Dillo devs be interested in the patches? Regards Jeremy Henty [1] Nginx spontaneously decided not to run until I tweaked its configuration. No idea why, but at least it is fixed.

2 1

a different lines->getRef() segfault
by eocene＠gmx.com March 2, 2015

March 2, 2015

A new page was just coming in -- seems like the same sort of problem as last time. (gdb) bt #0 0xb77bb424 in __kernel_vsyscall () #1 0xb72f9661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb72fca92 in *__GI_abort () at abort.c:92 #3 0xb72f2878 in *__GI___assert_fail ( assertion=0x8151afe "i >= 0 && this->num - i > 0", file=0x8151aee "../lout/misc.hh", line=167, function=0x8151ba0 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 #4 0x080a9040 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( this=0x953b618, i=-1) at ../lout/misc.hh:167 #5 0x080a2786 in dw::Textblock::sendSelectionEvent (this=0x916c610, eventType=dw::core::SelectionState::BUTTON_RELEASE, event=0xbfbb8180) at textblock.cc:1093 #6 0x080a24c3 in dw::Textblock::buttonReleaseImpl (this=0x916c610, event=0xbfbb8180) at textblock.cc:1008 #7 0x080d8910 in dw::core::Widget::buttonRelease (this=0x916c610, event=0xbfbb8180) at widget.cc:1027 #8 0x080cd617 in dw::core::Layout::processMouseEvent (this=0x90fc058, event=0xbfbb8180, type=dw::core::Layout::BUTTON_RELEASE) at layout.cc:1234 #9 0x080cd00e in dw::core::Layout::buttonEvent (this=0x90fc058, type=dw::core::Layout::BUTTON_RELEASE, view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) at layout.cc:1023 #10 0x080c46ae in dw::core::Layout::buttonRelease (this=0x90fc058, view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) at layout.hh:345 #11 0x080c33f7 in dw::fltk::FltkViewBase::handle (this=0x90f9f60, event=2) at fltkviewbase.cc:319 #12 0x080c5e8a in dw::fltk::FltkViewport::handle (this=0x90f9f60, event=2) at fltkviewport.cc:331 #13 0x080ded22 in send(int, Fl_Widget*, Fl_Window*) () #14 0x080dfbaf in Fl::handle_(int, Fl_Window*) () #15 0x080dff0e in Fl::handle(int, Fl_Window*) () #16 0x08107e9d in fl_handle(_XEvent const&) () #17 0x08107fbc in do_queued_events() () #18 0x0810822a in fl_wait(double) () #19 0x080e08af in Fl::wait(double) () #20 0x080e099d in Fl::run() () #21 0x08052f7a in main (argc=1, argv=0xbfbb8854) at dillo.cc:588

2 2

what's currently broken in dillo
by eocene＠gmx.com Feb. 28, 2015

Feb. 28, 2015

from my notes. I think all of this was mentioned on list: --local ... reload turns off URL_SpamSafe, but there it is again upon repush. > I found that shift+arrows in the url bar is doing nothing instead > of selecting the text. Ctrl+shift+arrows work fine. dd search url not removed when dillorc has search urls. background image oddities Jan 15 jan 17 edge.org page parbreak issue another lines->getRef segfault Jorge's slashdot hang the interlaced gif on forum.thinkpads.com feb 10 news.sciencemag.org hangs As for speed, I'd spent enough time with dillo being pretty slow before those optimizations were made in the past month or two that I've somewhat lost my feel for how fast dillo is supposed to be...

3 2

outofflowmgr.cc:1527: Assertion `yReq >= 0' failed.
by eocene＠gmx.com Feb. 12, 2015

Feb. 12, 2015

outofflowmgr.cc:1527: void dw::OutOfFlowMgr::tellFloatPosition(dw::core::Widget*, int): Assertion `yReq >= 0' failed. At http://darwinday.org/events/ #0 0xb775e424 in __kernel_vsyscall () #1 0xb7083661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7086a92 in *__GI_abort () at abort.c:92 #3 0xb707c878 in *__GI___assert_fail (assertion=0x8158124 "yReq >= 0", file=0x8158073 "outofflowmgr.cc", line=1527, function=0x81584a0 "void dw::OutOfFlowMgr::tellFloatPosition(dw::core::Widget*, int)") at assert.c:81 #4 0x080b8016 in dw::OutOfFlowMgr::tellFloatPosition (this=0x844f5b0, widget= 0x8cda630, yReq=-1348746332) at outofflowmgr.cc:1527 #5 0x080b7fdd in dw::OutOfFlowMgr::tellPosition (this=0x844f5b0, widget=0x8cda630, yReq=-1348746332) at outofflowmgr.cc:1516 #6 0x080aed85 in dw::Textblock::wrapWordInFlow (this=0x844ed10, wordIndex=9, wrapAll=true) at textblock_linebreaking.cc:788 #7 0x080ae8c0 in dw::Textblock::wordWrap (this=0x844ed10, wordIndex=9, wrapAll=true) at textblock_linebreaking.cc:606 #8 0x080b1842 in dw::Textblock::showMissingLines (this=0x844ed10) at textblock_linebreaking.cc:2113 #9 0x080a431d in dw::Textblock::sizeRequestImpl (this=0x844ed10, requisition=0xbfeaa950) at textblock.cc:342 #10 0x080dafc0 in dw::core::Widget::sizeRequest (this=0x844ed10, requisition=0xbfeaa950) at widget.cc:494 #11 0x080b71c7 in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x844f5b0, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #12 0x080b67ae in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x844f5b0, caller=0x844ed10) at outofflowmgr.cc:651 #13 0x080a4e6b in dw::Textblock::sizeAllocateImpl (this=0x844ed10, allocation=0xbfeaab00) at textblock.cc:759 #14 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x844ed10, allocation=0xbfeaab00) at widget.cc:993 #15 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8468b58, allocation=0xbfeaabf0) at textblock.cc:744 #16 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8468b58, allocation=0xbfeaabf0) at widget.cc:993 #17 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8468278, allocation=0xbfeaace0) at textblock.cc:744 #18 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8468278, allocation=0xbfeaace0) at widget.cc:993 #19 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x89c7ed8, allocation=0xbfeaadd0) at textblock.cc:744 #20 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x89c7ed8, allocation=0xbfeaadd0) at widget.cc:993 #21 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8a04228, allocation=0xbfeaaeb0) at textblock.cc:744 #22 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8a04228, #23 0x080d0230 in dw::core::Layout::resizeIdle (this=0x83a3688) at layout.cc:912 #24 0x080be150 in dw::fltk::FltkPlatform::generalIdle (this=0x83946e0) at fltkplatform.cc:630 #25 0x080be0d8 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x83946e0) at fltkplatform.cc:620 #26 0x08106e5c in call_idle() () #27 0x080e3eb5 in Fl::wait(double) () #28 0x080e3ff5 in Fl::run() () #29 0x08053b6f in main (argc=2, argv=0xbfeab0d4) at dillo.cc:590

1 0

page that hangs
by eocene＠gmx.com Feb. 10, 2015

Feb. 10, 2015

news.sciencemag.org Under gdb, breaking in and having a look at the backtrace always showed a series of rewrap()... (gdb) bt #0 0x08051680 in mcount at plt () #1 0x080b753f in lout::object::TypedPointer<dw::Textblock>::~TypedPointer ( this=0xbfffedf4, __in_chrg=<optimized out>) at ../lout/object.hh:115 #2 0x080b5b36 in dw::OutOfFlowMgr::getTextblock (this=0x825aa00, textblock=0x862f5e0) at outofflowmgr.cc:1956 #3 0x080b6aa1 in dw::OutOfFlowMgr::getAllocation (this=0x825aa00, textblock=0x862f5e0) at outofflowmgr.hh:252 #4 0x080b288c in dw::OutOfFlowMgr::Float::ComparePosition::compare ( this=0xbfffef7c, o1=0xbfffef28, o2=0x83eb728) at outofflowmgr.cc:233 #5 0x080db204 in lout::container::untyped::Vector::bsearch (this=0x82466c8, key=0xbfffef28, mustExist=false, start=0, end=5, comparator=0xbfffef7c) at container.cc:239 #6 0x080b6d8b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x82466b0, key=0xbfffef28, mustExist=false, start=0, end=5, comparator=0xbfffef7c) at ../lout/container.hh:451 #7 0x080b2cba in dw::OutOfFlowMgr::SortedFloatsVector::find (this=0x82466b0, textblock=0x862f5e0, y=61080, start=0, end=5) at outofflowmgr.cc:385 #8 0x080b2d73 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst ( this=0x82466b0, textblock=0x862f5e0, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:432 #9 0x080b6069 in dw::OutOfFlowMgr::getFloatHeight (this=0x825aa00, textblock=0x862f5e0, side=dw::OutOfFlowMgr::LEFT, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1) at outofflowmgr.cc:2143 #10 0x080b5fc5 in dw::OutOfFlowMgr::getLeftFloatHeight (this=0x825aa00, textblock=0x862f5e0, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1) at outofflowmgr.cc:2125 #11 0x080ae637 in dw::Textblock::calcBorders (this=0x862f5e0, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2058 #12 0x080ac011 in dw::Textblock::balanceBreakPosAndHeight (this=0x862f5e0, wordIndex=0, firstIndex=0, searchUntil=0xbffff168, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0xbffff16f, wrapAll=false, diffWords=0xbffff170, wordIndexEnd=0xbffff164, lastFloatPos=0xbffff158, regardBorder=true, height=0xbffff160, breakPos=0xbffff15c) at textblock_linebreaking.cc:910 #13 0x080abc03 in dw::Textblock::wrapWordInFlow (this=0x862f5e0, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:746 #14 0x080ab87c in dw::Textblock::wordWrap (this=0x862f5e0, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 #15 0x080ae17c in dw::Textblock::rewrap (this=0x862f5e0) at textblock_linebreaking.cc:1891 #16 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862f5e0, requisition=0x8635f80) at textblock.cc:341 #17 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862f5e0, requisition=0x8635f80) at widget.cc:494 #18 0x080ae159 in dw::Textblock::rewrap (this=0x862f098) at textblock_linebreaking.cc:1889 #19 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862f098, requisition=0x862f370) at textblock.cc:341 #20 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862f098, requisition=0x862f370) at widget.cc:494 #21 0x080ae159 in dw::Textblock::rewrap (this=0x862ea18) at textblock_linebreaking.cc:1889 #22 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862ea18, requisition=0x862ee18) at textblock.cc:341 #23 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862ea18, requisition=0x862ee18) at widget.cc:494 #24 0x080ae159 in dw::Textblock::rewrap (this=0x862b748) at textblock_linebreaking.cc:1889 #25 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862b748, requisition=0x862b9f8) at textblock.cc:341 #26 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862b748, requisition=0x862b9f8) at widget.cc:494 #27 0x080ae159 in dw::Textblock::rewrap (this=0x862b0a0) at textblock_linebreaking.cc:1889 #28 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862b0a0, requisition=0x862b478) at textblock.cc:341 #29 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862b0a0, requisition=0x862b478) at widget.cc:494 #30 0x080ae159 in dw::Textblock::rewrap (this=0x835e868) at textblock_linebreaking.cc:1889 #31 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x835e868, requisition=0x855357c) at textblock.cc:341 #32 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x835e868, requisition=0x855357c) at widget.cc:494 #33 0x080ae159 in dw::Textblock::rewrap (this=0x82846b8) at textblock_linebreaking.cc:1889 #34 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x82846b8, requisition=0xbffff750) at textblock.cc:341 #35 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x82846b8, requisition=0xbffff750) at widget.cc:494 #36 0x080b4183 in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x825aa00, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #37 0x080b376a in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x825aa00, caller=0x82846b8) at outofflowmgr.cc:651 #38 0x080a1e27 in dw::Textblock::sizeAllocateImpl (this=0x82846b8, allocation=0xbffff8f0) at textblock.cc:759 #39 0x080d8e4f in dw::core::Widget::sizeAllocate (this=0x82846b8, allocation=0xbffff8f0) at widget.cc:993 #40 0x080cd1ec in dw::core::Layout::resizeIdle (this=0x81f2940) at layout.cc:912 #41 0x080bb10c in dw::fltk::FltkPlatform::generalIdle (this=0x81e2d38) at fltkplatform.cc:630 #42 0x080bb094 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x81e2d38) at fltkplatform.cc:620 #43 0x08103e18 in call_idle() () #44 0x080e0e71 in Fl::wait(double) () #45 0x080e0fb1 in Fl::run() () #46 0x08052f7a in main (argc=1, argv=0xbffffb14) at dillo.cc:588

1 0

Core-dump pasting from one form field into another
by james.from.wellington＠gmail.com Feb. 2, 2015

Feb. 2, 2015

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)

4 8