tag:blogger.com,1999:blog-83363265627419446262024-03-23T03:14:26.803-07:00CRiSP, DTrace, and other technobabbleTechnoblog with some random mutterings and ramblingsCrisp Editorhttp://www.blogger.com/profile/14144625547464350210noreply@blogger.comBlogger321125tag:blogger.com,1999:blog-8336326562741944626.post-2277301607769370252015-05-03T12:30:00.001-07:002015-05-03T12:30:09.205-07:00New website - stop it !The new website www.crispeditor.co.uk is live, and its interesting to<br />watch who is accessing it. Right now, there are two main attempts<br />at cracking it - one is a WordPress vulnerability and the other, is<br />a PHP one. I guess the bots are hungry for food.<br /><br />Also, it is interesting how quickly both Google and Bing start their bot<br />machines. That is encouraging. Very soon, I will be the most popular<br />website in the solar system - just keep <a href="http://www.crispeditor.co.uk">clicking</a><br />and we might make it into the Interweb Hall of Fame.<br /><br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.6a-b6833<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com1tag:blogger.com,1999:blog-8336326562741944626.post-53143187674244390482015-05-02T01:20:00.001-07:002015-05-02T01:20:38.301-07:00http://www.crispeditor.co.uk - now liveThe domain transfer and contents transfer is complete - the links on the <br />website can now be used to download copies of CRiSP, DTrace and other tools.<br />I will need to tidy up some of the very old contents.<br /><br />Please mail me at crispeditor at gmail.com if you see any issues.<br /><br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.6a-b6833<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com1tag:blogger.com,1999:blog-8336326562741944626.post-61603027550033723312015-04-30T15:20:00.001-07:002015-04-30T15:20:18.481-07:00http://www.crispeditor.co.ukThe new replacement and home for the very old Demon website, where<br />you can download copies of CRiSP is nearly ready. You can visit the website<br />at<br /><br />http://www.crispeditor.co.uk<br /><br />and you will find content and download links, but the links will be a bit<br />stale as I copy things around. Hope to have this at parity in the next day<br />or so.<br /><br />You may not be able to actually download anything, but thats high<br />on the list to fix.<br /><br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.5a-b6832<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-37908817489477147682015-04-26T13:35:00.001-07:002015-04-26T13:35:32.041-07:00Goodbye Demon - shame the service is so badI joined Demon Internet back in 1992 - the first service provider<br />in the UK, and home for CRiSP (www.crisp.demon.co.uk) for the last 23y.<br /><br />Despite various ownership changes of the company, it seems that the<br />FTP service is no longer functioning and I will finally retire my<br />Demon account this year.<br /><br />For those of you looking to find CRiSP, you will find that eventually<br />that website will vanish, and I will replace with another site - once<br />I have decided on the best options.<br /><br />My gmail accounts will continue to work, but my demon email address will<br />stop working at some point. <br /><br />This is just a heads up.<br /><br />I hope I am wrong and the FTP service recovers, but it seems like Demon<br />are transferring the hosting services to another provider, and nobody at<br />Demon understands the product they own, so it appears.<br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.5a-b6832<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-30882849817272280862015-03-01T13:12:00.001-08:002015-03-01T13:12:21.815-08:00another dtrace delayEverything was looking promising to release a new dtrace sometime last<br />week. It was working on the 3.16 kernel, 3.8, 3.4 and then onto RH5.6 (2.6.18).<br />I ran into a lot of issues on 2.6.18 - not surprising, given the code<br />mutations. Much of the last 2 weeks was on the execve() system call.<br />It would panic the kernel. Despite a lot of experiments and reading<br />of the assembler and kernel code, I kept doing silly things. It<br />really doesnt help that the 2.6.18 kernel will hard panic on a stray<br />GPF - made it very difficult to figure out what was going on.<br /><br />Eventually I got every line of assembler and issues with registers in C<br />code to work. <br /><br />Along the way I had an issue with the "old_rsp" symbol. This is not exposed<br />in /proc/kallsyms, and not even in the /boot/System.map code. I had<br />to write a tool to extract this from inside the kernel. But this ran into<br />complications because /proc/kcore is broken on the RH/Centos kernels. I<br />had to create a new device driver, which has to be loaded into the kernel<br />prior to the build of dtrace ("/proc/dtrace_kmem"). Its a very simple<br />driver only designed to handle the scenario of building dtrace.<br /><br />Having got this work, then the next roadblock was the rt_sigreturn() syscall<br />which paniced the kernel. Careful investigation showed a missing line<br />of assembler (for the 2.6.18 kernel). Now that works.<br /><br />Now everything is looking good on RH5/Centos5 but before going on the<br />trawl of later kernels and proving I didnt break anything, I have an<br />issue with x_call.c. Either I use the native smp_call_function() interface -<br />which works great, until we panic the kernel, or I use my implementation,<br />which doesnt seem to be broadcasting to the cpus - this means<br />certain probes get "lost".<br /><br />So, hopefully this week or next weekend - depending on the xcall issues.<br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.3a-b6808<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com3tag:blogger.com,1999:blog-8336326562741944626.post-50263817272791069202015-02-23T13:57:00.001-08:002015-02-23T13:57:08.036-08:00dtrace update ...Still delaying the dtrace release. Having gotten 3.16 kernels to work,<br />I started working backwards on random 3.x kernels, to validate it<br />still worked there. I fixed a number of issues there, and then headed<br />into RedHat 5.6 / Centos 5.6 land (2.6.18+ kernel).<br /><br />I spent some time trying to get execve() syscall tracing to work - and<br />am still working on that. <br /><br />Along my journey, I noticed a few things. Firstly dtrace4linux is too<br />complicated - trying to support 32+64b kernels, along the entire<br />path back to 2.6.18 or earlier, is painful. I cannot easily automate<br />regression testing (not without a lot more hard-disk space, and not<br />worthwhile whilst I am aware of obvious bugs to fix). I could simplify<br />testing by picking any release, and just rebooting with different kernels -<br />rather than full ISO images of RedHat/Centos/Ubuntu/Arch and so on.<br /><br />I also noticed that the mechanism dtrace4linux uses to find addresses in<br />the kernel is slightly overkill. It hooks into the kernel to find symbols<br />which cannot be resolved at link time. The mechanism I have is pretty <br />interesting - relying on a Perl script to locate the things it needs.<br />I found a case where one of the items I need is not visible at all<br />in user space - its solely in the kernel - part of the syscall interrupt<br />code (the per-cpu area). Despite what latest kernels do, some older<br />kernels *dont*. And catering for them is important. In one case<br />I have had to go searching the interrupt code to find this value.<br />I ended up writing a C program to run in user space, prior to the build,<br />and really, it would have been better to generalise this so that everything<br />we need is simply defined in a table compiled in to the code, rather than<br />the /dev/fbt code to read from the input stream. This would ensure<br />that a build compiles and works. Today, sometimes I debug issues with<br />old kernels because a required symbol is missing and we end up <br />dereferencing a null pointer (not a nice thing to do in the kernel).<br /><br />One problem I had with the above, was that gdb on the older distro releases<br />cannot be used to read kernel memory due to a bug in the kernel<br />precluding reading from /proc/kcore. Fortunately, I include a script<br />in the release which emits a vmlinux.o, complete with symbol table,<br />from the distribution vmlinuz file.<br /><br />I havent reverified the ARM port of dtrace, but thats something for a<br />different rainy or snowy day.<br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.3a-b6808<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-70539651472599514462015-02-20T10:11:00.001-08:002015-02-20T10:11:40.424-08:00new dtrace .. small updateThe next release of dtrace is hopefully this weekend. Having<br />resolved the issues I had previously, have been doing more <br />testing - so far only really on the 3.16 kernel, and found that<br />some of the syscalls were behaving badly due to reimplementation<br />in the kernel. Hopefully when I have fixed the last two or three,<br />then I can finish my merges and push out the latest release. I will<br />do a cursory check on some of the older kernels - it is likely I<br />have made a mistake somewhere and broken older kernels, but will<br />be easier to fix having made some internal changes.<br /><br />Note that no new functionality is in here - the issues with<br />libdwarf remain - I may try again to solve that issue, and <br />"dtrace -p" is still a long way off from being functional.<br /><br />Given that 3.20 is now the current kernel, I may need to see<br />if that works and pray that 3.17-3.20 didnt affect how dtrace works,<br />or, if it does, the work to make it compile should be much less<br />than the issues that 3.16 raised.<br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.3a-b6801<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-57255689602281791812015-02-19T15:09:00.001-08:002015-02-19T15:09:22.510-08:00Why is gcc/gdb so bad?When gcc 0.x came out - it was so refreshing. A free C compiler.<br />GCC evolved over the years, got slower and used more memory. I used<br />to use gcc on a 4MB RAM system (no typo), and wished I had 5MB RAM.<br />Today, memory is cheap, and a few GB to compile code is acceptable.<br />(The worst I have seen is 30+GB to compile a C++ piece of code - not<br />mine!)<br /><br />One of the powerful features of gcc was that "gcc -g" and "gcc -O"<br />were not exclusive. And gdb came about as a free debugger, complimenting<br />gcc.<br /><br />Over recent years, gdb has become closer to useless. It is a powerful<br />and complex and featureful debugger. But I am fed up single stepping<br />my code, and watching the line of execution bounce back and forth<br />because the compiler emits strange debug info where we move back<br />and forth over lines of code and declarations.<br /><br />Today, in debugging fcterm - my attempt to place a breakpoint<br />on a line of code, puts the breakpoint *miles* away from the place I<br />am trying to intercept. This renders "gcc -g" close to useless, unless<br />I turn off all optimisations, and pray the compiler isnt inlining code.<br /><br />Shame on gcc. Maybe I should switch to clang/llvm.<br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.3a-b6801<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com1tag:blogger.com,1999:blog-8336326562741944626.post-11374900115490762502015-02-15T14:18:00.001-08:002015-02-15T14:18:24.574-08:00address: 0000f00000000000Strange. Continue to keep finding why dtrace is not passing my tests.<br />I have narrowed it down to a strange exception. If the user script<br />accesses an invalid address, we either get a page fault or a GPF.<br />DTrace handles this and stubs out the offending memory access. Heres<br />a script<br /><br /><pre><br />build/dtrace -n '<br /> BEGIN {<br /> cnt = 0;<br /> tstart = timestamp;<br /> }<br /> syscall::: {<br /> this->pid = pid;<br /> this->ppid = ppid;<br /> this->execname = execname;<br /> this->arg0 = stringof(arg0);<br /> this->arg1 = stringof(arg1);<br /> this->arg2 = stringof(arg2);<br /> cnt++;<br /> }<br /> tick-1s { printf("count so far: %d", cnt); }<br /> tick-500s { exit(0); }<br />'<br /></pre><br /><br />This script will examine all syscalls and try and access the string<br />for arg0/1/2 - and for most syscalls, there isnt one. So we end up<br />dereferencing a bad pointer. But only some pointers cause me pain.<br />Most are handled properly. The address in the title is one such address.<br />I *think* what we have is the difference between a page fault and a GPF.<br />Despite a lot of hacking to the code - I cannot easily debug, since<br />once this exception happens the kernel doesnt recover. I have modified<br />the script above to only do syscall::chdir: which means I can manually<br />test via a shell, doing a "cd" command. On my 3-cpu VM, I lose one of the<br />CPUs and the machine behaves erratically. Now I need to figure out if<br />we are getting a GPF or some other exception.<br /><br />I tried memory addresses: 0x00..00f, 0x00..0f0, 0x00..f00, ... in order<br />to find this. I suspect there is no page table mapping here or its<br />special in some other way. May need to dig into the kernel GDT or<br />page table to see what is causing this.<br /><br />UPDATE: 20150215<br /><br />After a bunch of digging I found that the GPF interrupt handler had<br />been commented out. There was a bit more to this than that, because<br />even when I re-enabled it, I was getting some other spurious issues.<br />All in all, various bits of hack code and debugging had got in the way<br />of a clear message.<br /><br />I have been updating the sources to merge back in the fixes<br />for the 3.16 kernel, but have a regression on syscall tracing which<br />can cause spurious panics. I need to fix that before I do a next<br />release.<br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.3a-b6801<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-48088389556018576192015-02-09T15:09:00.001-08:002015-02-09T15:09:13.974-08:00no dtrace updatesPeople have been questioning why there are no dtrace updates.<br />I hope to be in a position to properly respond shortly. Just before<br />Christmas, I started work on Debian Jessie (3.16 kernel) and hit a number<br />of issues. Although I made good progress fixing issues on x32 syscalls on<br />a x64 system, and systematically fixing other issues, I had to hack the<br />driver tremendously. These hacks are experiments to figure out why<br />I could so easily crash the kernel. The usual means of panicing the<br />kernel did not hold - normally a stray issue causes a kernel message<br />and I can debug around the issue to isolate the cause.<br /><br />The issues I hit were all very low level - the cross-cpu calls, the<br />worker interrupt thread, and the current issue - relating to invalid<br />pointers when accessed via a D script. I have a "hard" test which wont<br />pass without crashing the kernel - crashing the kernel really hard,<br />requiring a VM reboot. This is nearly impossible to debug. The first<br />thing I had to do was increase the console mode terminal size - when<br />the panic occurs, the system is totally unresponsive and all I have<br />is the console output to look out, with no scrolling ability. Having<br />a bigger console helps - but it seems like the GPF or PageFault interrupt,<br />when occuring inside the kernel, does not work the same way as<br />it has on all prior Linux kernels. Looking closely at the<br />interrupt routines shows some changes in the way this works - enough<br />to potentially cause a paniccing interrupt to take out the whole <br />kernel; this makes life tough to debug.<br /><br />If I am lucky, the area of concern is related to the interrupt<br />from kernel space. If I am unlucky, it is not this, but something else.<br />(Am hypothesing that the kernel stacks may be too small).<br /><br />I have been saving up putting out any updates, despite some<br />pull requests from people, because I am not happy the driver is in<br />a consistent state to release. When I have finished this area<br />of debugging, I can cross-check the other/older kernels, and see if<br />I have broken anything.<br /><br />It is very painful dealing with hard-crashing kernels - almost nothing<br />helps in terms of debugging, so am having to try various tricks to<br />isolate the instability. These instabilities in theory, exist on other<br />Linux releases - but I will only know when I have gotten to the bottom<br />of the issue.<br /><br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.3a-b6801<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-26620473202693300902014-12-01T14:56:00.001-08:002014-12-01T14:56:23.390-08:00DTrace & Debian/JessieSomeone reported a bug in dtrace whereby execve() wasnt tracing.<br />I created a VM and started testing, and can confirm this. Looks<br />like dtrace is getting confused by the new rewritten syscall assembler.<br />I have a working version for this in my testbed, but I found that<br />changes to the IPI code in the kernel are making any dtrace probes<br />extremely unreliable - looks like a 1:N chance of seeing output (where<br />N is the number of cpus you have).<br /><br />I have some similar issues in Ubuntu 14.04 - hopefully similar issues.<br /><br />Hope to have a new release shortly in a few days.<br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.3a-b6801<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-428656347077277162014-11-08T15:58:00.001-08:002014-11-08T15:58:26.596-08:00CRiSP/crtags OptimisationThe tagging facility in CRiSP has always worked reasonably well - it<br />is based on a series of custom parsers for each programming language.<br />Over the years, the list of languages supported has grown and is<br />now a huge repository of nearly every common language and file<br />format out there. (See: "crtags -help" for details).<br /><br />The initial implementation is getting on for nearly 20y old.<br />The goal originally was to provide the "ctags" facility of vi,<br />but better. Machines of the day were looking like 4-16MB of RAM rather<br />than 4-16GB of RAM which is common today, so effort was made to <br />optimise space usage. The crtags file format is a series of sections<br />of files and items which are tagged. It has been optimised - right<br />from the beginning, to avoid optimise space usage, and avoid bad<br />paging behavior. (Now, a distant artifact ! Systems rarely page or<br />are memory constrained). This attempt to optimise memory goes back to the<br />1MB machines that CRiSP was originally built on. These optimisations<br />are no longer necessary - but removing them would only offer a small<br />change in performance.<br /><br />crtags is designed to work with reasonably sized projects and directories.<br />It takes a few seconds to scan the nearly 8000 files in the CRiSP source<br />tree, and I regularly use it on the Linux kernel. The 3.16.1 kernel<br />has 47426 files in it. Scanning that takes a little while. I have benchmarked<br />this over the years.<br /><br />Recently I did some more work to look at the performance and optimisation<br />facilities in crtags. I collected a series of Linux kernels - so<br />I would have a good/large test case - about 500MB of source files,<br />67356 files in all. On my i7 laptop (crtags is single threaded), it was<br />taking about 2m20s to scan the files. On investigating the performance,<br />I could see that we had an O(n^2) algorithm on filename matching. This<br />is silly, given the complexity of the language parsers - that the mere<br />filenames were using a lot of the CPU. <br /><br />I modified the code to put in a hash table for filename matching,<br />and this gave a huge win - down to about 23s for scanning the same files -<br />about a 7x improvement in speed.<br /><br />In looking at crtags, most of the processing is a constant per file -<br />and each file is handled, one after the other. This opens up a huge<br />win by multithreading the code. Potentially an Nx speedup, on an N cpu system.<br />The code is difficult to convert to multithreading - it would require<br />a lot of edits and refactoring, to ensure each thread is<br />avoiding global state - a common reason why converting a non-threaded<br />application to multithreaded is so difficult. <br /><br />Its depressing how little attention the C standards bodies and <br />compiler writers have, for converting non-threaded code to threaded.<br />Really, there are a set of transformations (refactoring) and one would<br />think that tools could help identify the major areas at issue<br />(use of global variables, and use of "static" variables). I<br />may create a refactoring macro in CRiSP to handle this.<br /><br />On Unix, using a fork/join model of operation, one can create<br />the equivalent of a multithreaded code, by use of fork() and wait()<br />system calls. For example, divide all the files to be processed<br />up, into separate groups, processed by individual CPUs. Then the<br />issue of global state and locking disappears - at the expensive of<br />more work on the "join" or merge at the end of processing.<br /><br />I have modified crtags to use this fork/join model (it is a command<br />line option, and not enabled by default), and reran my test. The above<br />test went from 23s to 4s by using "crtags -j 8" - using the 4 real and<br />4 hyperthread cpu's on my i7. About a 6x performance increase.<br />(The final code will be slower due to the lack of a merge).<br /><br />So we went from 2m20s to 4s - a 35x speed up, with just a handful of lines<br />of code.<br /><br />The depressing thing about Windows (and this is late 2014) is that<br />it still does not support fork(). It does support threads. So the above<br />code will have no effect on Windows, and real threading will have to<br />be implemented or an alternate way of achieving the same result. <br /><br />I do fail to understand why Windows cant implement fork() - from<br />the user space point of view, there is almost nothing to implement.<br />From the kernel point of view, its not a huge amount of code.<br />Granted, Windows processes may carry more state and forking may<br />be more expensive if Windows could do it, but that would be such<br />a big benefit when writing portable code or porting code to Windows.<br />Oh well. (Cygwin supports fork(), and it is hugely expensive<br />in operation, since it relies on software to copy huge blocks<br />of memory around, rather than relying on the CPU's MMU to do<br />copy-on-write (COW) operation - the key to why fork() is so efficient<br />on Unixes).<br /><br />Having said that, fork() on Linux is not brillliantly fast. Despite<br />processors being so much faster than years of old - fork() seems<br />to be getting slower, possibly related to the need for all<br />CPUs to synchronise MMU and other state, rather than fork() itself<br />getting more complicated.<br /><br />To end users of CRiSP, they may see the initial performance optimisation,<br />but unless they are working on extremely huge projects, they may<br />hardly ever notice the change put in place. Also note, that<br />in CRiSP, one rarely tags an entire project - CRiSP does incremental<br />updates to the tag database, as you are editing/saving files.<br /><span class='post-comment-link'><br />Post created by CRiSP v12.0.3a-b6801<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-75516573074229410032014-09-06T12:58:00.001-07:002014-09-06T12:58:19.276-07:00Firefox, GMail and cookies (solved)I reported a while back, a problem with Firefox and inability to<br />login to gmail. After a restart of firefox, you get a cookie error<br />page. I found a solution was to tediously delete all google cookies - then<br />I could login. However, logging into my other account would, sooner or later,<br />give rise to the same cookie mismatch error. It was annoying<br />and infuriating. <br /><br />I had resorted to using my phone/tablet to handling email, but that seems<br />silly (except when on the road).<br /><br />After repeated scouring the web for solutions or solved solutions,<br />nothing worked. But I bumped into a reference regarding potential<br />issue with plugins.<br /><br />So I tried disabling all my firefox plugs, and it worked !<br /><br />So I then narrowed down which is the offending culprit.<br /><br />And the culprit is:<br /><br /><b>Flash Video Downloader - YouTube Full HD Download</b><br /><br />I dont know why, but I assume these plugins act as private<br />proxies, to intercept web requests, and somehow, it is mishandling<br />cookies.<br /><br />So I can relax that I hope this issue is finally over.<br /><br />I hope this is useful to others out there when faced with a similar<br />issue.<br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.35a-b6772<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-64435092232395620232014-08-26T08:05:00.001-07:002014-08-26T08:05:41.108-07:00Galaxy Tab S 8.4 / LTEI recently bought one of these devices. I didnt really need it,<br />but I wanted a larger version of my phone (Galaxy Note 2), for<br />video watching. I dislike my mini ipad - it is a great device to hold,<br />but the whole iOS experience leaves me very cold. That and the puny amount<br />of RAM. Switching between 3 apps will force restart the apps since<br />iOS cannot juggle the demands of only 3 apps in the 512MB of memory.<br /><br />My phone has 2GB and can easily keep 5-6 apps open. So app switching<br />is faster, because of the lack of a need to restart.<br /><br />The Galaxy Tab S has a screen of 2560x1600. Although brilliant from<br />a bragging rights, its difficult to appreciate what this means. What<br />it means to me is that when I split screen apps, I can read the smaller<br />fonts of info from web browser, IMDB, etc.<br /><br />There is definitely some lag in the device. I attribute this to code which<br />will synchronously try and connect somewhere. I rooted my device, put<br />in an adblocker, but sometimes the delays are much more than just bad<br />OS coding. Theres too many services all fighting to wake up and do<br />things, and even with a quad core cpu, it hangs. I run a tool to monitor<br />the CPU speed and when it is being sluggish, the CPUs are at their lowest<br />clock speed (250MHz) which suggests externally waiting for something<br />and not a CPU issue. I need to run more stuff to see whats going on, e.g.<br />a network monitoring.<br /><br />My major complaint with the Tab-S is its so big. I can easily hold<br />the Galaxy phones in my hand comfortably, in such a way that my fingers<br />cannot touch the screen. The same is not true of an 8" tablet. You either<br />gingerly hold it from the sides, e.g. the end where the Samsung label<br />is, because theres more room for your fingers, or the other end<br />where the home/back/menu button is located. That end of the tab is<br />bad news as the system sees you frantically pressing any/all of those buttons.<br /><br />If you attempt to grasph the device with your fingers mid-screen, chances<br />you are going to do something you regret (such as click on a link, or<br />fast-forward a video). Very strangely, the one advantage of iOS is <br />that it is such an unfunctional OS, that this does not happen<br />with the ipads. If you are watching a video and use your fingers<br />to grasp the middle of the screen, then nothing happens, because apple<br />doesnt attribute any activity to touching the middle of the view area.<br /><br />So, the one advantage that Android has (and MX-Player - brilliant video <br />player) is actually a problem on a large screen device, because there<br />is nowhere safe to hold the device.<br /><br />I really dont know what is happening with the edge-less phones<br />currently being touted. I dont know how you can hold one without<br />having a very erratic user experience from the edges<br />of your palm or fingers, just trying to hold the device.<br /><br />Only time will tell.<br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.34a-b6771<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-61718794227124602472014-08-12T14:17:00.001-07:002014-08-12T14:17:03.596-07:00Intel NUCMy NUC decided to die tonight. After only a few weeks. Luckily, google<br />helped me find the problem.<br /><br />It had lost its mind/marbles. It couldnt find the root hard drive.<br /><br />After fiddling in the BIOS, I found that resetting the defaults fixed<br />the problem.<br /><br />It is 2014. Issues with BIOS date back to around about 1990 or so - that<br />was when one bothered to go into the BIOS and configure pointless items.<br />Since then, stuff works. Thanks Intel. That really is poor software<br />development - a 24x7 machine suddenly needing a screen to reset the BIOS<br />settings.<br /><br />Yes, I need to update the BIOS, but go search for BIOS updates for NUC,<br />and be startingly confused by how many versions there are and advice<br />not to use the latest one.<br /><br />Why is the software industry going backwards? Its not just Intel. But<br />every major software manufacturer is adding functionality and usability<br />by actively removing it.<br /><br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.33a-b6757<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-52492150578356547402014-08-04T15:35:00.001-07:002014-08-04T15:35:16.116-07:00Keep at 'emI keep watching the stats on requests to my rss feed. Google seems<br />to like me, which is encouraging, and so do some other bots/trackers.<br /><br />I see the occasional nasty connection trying to break stuff, and<br />enjoy myself watching some of the attacks. I assume they are attacks<br />but there may be a reason for some of them. Eg a Japanese person<br />may be trying out a Unicode request, based on some indirect link<br />from google, for example.<br /><br />It did break a record today, and if this keeps up, I can start<br />figuring out how to really handle high load. At the moment,<br />the load is low, and even although the feed is written for speed of<br />development, and not optimal cpu usage - its a great exercise for<br />some future optimisations to really decide how to sustain higher<br />rates.<br /><br />I ought to give it a real name, since the P and Q pages are not<br />really indicative of what the service is.<br /><br />Definitely an interesting experiment. <br /><br />BTW I have used 250MB of mobile bandwidth in 3-4 months (to my phone).<br />I cannot believe how low my bandwidth is, now that all adverts and<br />other HTML window dressing is removed from the equation.<br /><br />Who needs 4G? This works at 9600 baud really well :-)<br /><br />http://crisp.publicvm.com:3000<br /><br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.33a-b6757<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-90145314264067346522014-07-21T13:42:00.001-07:002014-07-21T13:42:58.386-07:00Problems with RSS<a href='http://crisp.publicvm.com:3000/p.html'>RSS Feed</a><br /><br />Not sure what did it - maybe I ran as root, accidentally when I didnt mean<br />to, but nothing would update, despite changing permissions and resetting<br />some internal state. In the end decided just to clean it all out and<br />start again. If you are reading the feed, you likely wont notice much<br />and in a few hours, the differing RSS feeds will race ahead with their<br />usual updates.<br /><br />Despite the simplicity of the code, theres always a surprise lurking<br />in the code - but then, thats the fun of the fair !<br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.33a-b6757<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-42425908752693006152014-07-20T10:48:00.001-07:002014-07-20T10:48:41.294-07:00A real good read... (Xplain)<br /><a href='http://magcius.github.io/xplain/article/index.html'>Xplain</a><br /><br />I do like a good read, and the above link is a nicely written way to<br />understand X Windows and X11 and related. I remember the first time I heard<br />of X, and had some consultants explain it, a long long time ago. And it<br />took me a while to get used to it - the day I moved from a character based<br />terminal to a Sun/3 workstation with an infinite set of display options,<br />and a whoopingly large 1600x1200 display. It took nearly 20y to be able to<br />afford one of these at home, and today, we finally have 1920x1080 (alas,<br />no more 1920x1200), 2560x1440, 3200x1800 and real 4k and 8k screens<br />coming, with prices dropping on a weekly basis.<br /><br />Have fun<br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.33a-b6757<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-56491820999211094012014-07-12T11:32:00.001-07:002014-07-12T11:32:44.014-07:00A sad day...A glorious dayIt is a sad day. I am going to decommission the CRiSP FTP server.<br />This is a macmini - PPC vintage (400MHz) I think. It has performed<br />absolutely admirably. 9y of service - the oldest file seems to<br />be March 2005. <br /><br />At the time the PPC mac mini came out - it was a brilliant device.<br />It still is. It has not murmured in the last 9y, despite 24x7 operation.<br />A *huge* 80G hard drive, 256MB of RAM. This is a *big* machine compared<br />to my earliest machine. (My earliest machine - had *1K* of RAM; my<br />first real PC had 4MB of RAM, 20MHz i386 and 20MB of disk space). My<br />Galaxy Gear watch beats the pants out of all of these.<br /><br />The PPC (I cally it "minny") hasnt misbehaved - but it was<br />murmuring a little - but I attribute this to either some DNS lookup<br />delays, or my news aggregator Perl script. The news aggregator<br />(<a href='http://crisp.publicvm.com:3000/'>http://crisp.publicvm.com:3000/</a>)<br />has a bug/memory leak, so after a few weeks of operation its used about<br />200min of CPU and a whopping 40MB of RAM. One of my weekend jobs is<br />to fix the memory leak.<br /><br />Now the good news. Intel NUC. I keep seeing these devices, and they<br />are cute. Of course, one never buys a machine because it is cute, but,<br />err...ok, I did. The Intel NUC (go see Amazon or Intel for details) is<br />a device slightly taller than the old style Mac Mini, but smaller - about<br />the size of a CD case. I kept trying to decide what to do; previously<br />I had purchased a Raspberry Pi, as a replacement for minny, but I was not<br />happy with the Pi - too low performance, horrible dangly wires and <br />protusions and unreliable power supply. The NUC is good - I opted<br />for the outdated Intel Celeron model - the cheapest. I thought I would<br />use USB for hard drive or an SSD disk. But why pay for SSD. A 1TB<br />disk was about 50 pounds. Add 26 pounds for 4GB RAM, and we are looking<br />at a new machine for about 170 pounds. The machine screams.<br /><br />I installed Ubuntu 14.04 - the same as my other machines, and I can now<br />divorce myself from the PPC vs x86 binary compatibility problems.<br /><br />I never filled the 80GB drive in the mac mini and I definitely wont<br />fill the 1TB drive in the new machine. Of course, the new machine needs<br />a name - "nucky" - after Nucky Thompson, from "Boardwalk". <br /><br />I am presently copying the old crisp releases on to the machine so it can<br />transparently take over from minny. And thats about it.<br /><br />In all the years of minny - bots have been continuously attempting<br />automated dictionary attacks to break into the machine. Maybe, because<br />its a PPC, that no-one ever succeeded. I like to think they wont<br />on nucky, but, there is nothing to steal from there. It would be<br />darned annoying.<br /><br />This new "mini" machine is great; I might get a higher end one - an i3 or i5,<br />but the price differential seems obsurd. The Celeron chip is a dual<br />core chip - with a decent size cache. Its a great CPU for this purpose. It<br />might not be for intensive video (but should be sufficient for watching<br />videos), or gaming.<br /><br />So, say hello to "nucky" the next time you grab some news from the<br />aggregator, or a copy of CRiSP, or a copy of dtrace, etc.<br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.33a-b6757<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-3221002232119284322014-07-12T07:10:00.001-07:002014-07-12T07:10:01.601-07:00sort -V : Thanks. That was not helpfulWas just looking at the code in CRiSP which checks whether a new<br />software update is available. It works by downloading an index<br />file with version information, and comparing the version<br />you are running against the master index. Very<br />simply mechanism.<br /><br />The current latest release of CRiSP (for linux 32/64 bit systems), is<br />11.0.32. I am staring at the generated file, and it says "11.0.9". So,<br />anyone using the "Check for updates" menu in CRiSP will have no idea<br />that new versions are available.<br /><br />But why?<br /><br />Looking at the script to generate the updates - the last time I touched<br />this was in 2003. I know the script worked at some point in the last<br />few years. I rarely need to see if I am running the latest version of<br />CRiSP - so it would not show up as an issue.<br /><br />The root of the issue lies in how the script gets an index<br />of all the indexed files:<br /><br /><pre><br />get_latest ()<br />{<br /> find . -name crisp-$1-b\*.* -print |<br /> sed -e 's;^./;;' | sort -n | tail -1<br />}<br /></pre><br /><br />The "find" command is getting a list of filenames - files are stored<br />in version directories (eg 11.0.31/). And because the build (b) number<br />is at the end of the filename, we want to sort all the available versions<br />of the files, but we want to sort numerically on the version numbers.<br />This means that something like:<br /><br /><pre><br />10.0/crisp-linux-b1234.tar.gz<br />...<br />11.0/crisp-linux-b2345.tar.gz<br /></pre><br /><br />would come out in a natural order. The "sort -n" does that in the<br />shell script above. <br /><br />Turns out the "sort" people changed the behavior of a numeric sort<br />in the presence of text: they ignore the attempt to sort! So<br />instead of generating a list of the most recent versions of CRiSP,<br />we have a list of the oldest versions available instead. Not very<br />helpful. A quick scan of "sort"'s switches shows that I needed<br />to use "-V". I had never seen it before, but am glad it is there and<br />now generates the correct version information.<br /><br />This illustrates a problem with all software, that by depending on<br />other tools and libraries, you will one day be silently broken<br />and may not realise it.<br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.33a-b6754<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-49794908350970914792014-06-26T15:03:00.001-07:002014-06-26T15:03:18.239-07:00Musing on Android WearI have a Galaxy Gear 1 watch. I consider it to be a great gadget -<br />I became comfortable flashing the "null_" ROM on it, and the fact<br />that I can "adb" to talk to the device of USB is great. I dont like<br />Android - simply because its a bastardised Linux kernel. I somewhat<br />refuse to use Eclipse to create apps or edit files, when CRiSP serves<br />all my needs. The lack of a proper shell is a real nuisance. The<br />built in shell, and lack of root/su is really a two finger exercise<br />to the people who pay for these products. (This includes all Android <br />phones and tablets).<br /><br />OTOH, I love the freedom of Android compared to the Apple products;<br />I love Samsungs multi-window mode - I just wish Apple and Google would<br />wake up to adding real features I want, rather than rejiggling the<br />Setup menus on each release, and preventing me from either deleting or<br />removing the built in apps. There are more and more Google apps, and<br />I have a hard time telling what they do and try to avoid them. (Not all<br />of them, but the "we know what you want - HERE YOU ARE!" is annoying;<br />Apple and Microsoft are no different).<br /><br />But I am talking about watches. Not long after the Galaxy Gear 1<br />came out was the Tizen based Galaxy Gear 2 (or whatever Samsung<br />want to call it). A really good way to destroy customer loyalty by<br />confusing and diluting the market. Fortunately, you can put Tizen<br />on to the Gear 1 (see xda-forums - brilliant site). I dont know *why*<br />I would want to do that; and a few months later (i.e. now), we have<br />Android Wear. I feel I have walked into a department store and<br />am trying to choose from the 300 brands of soap!<br /><br />The Galaxy Gear 1 is great - fairly robust; let down by amateurish<br />software and user interface (why do I get to choose from "white" or<br />"orange" text? What happened to the other 2^24-2 colors?)<br /><br />But heres the kicker. Because it has to be charged daily, I have<br />to take it off at night. And, in the morning, I forget to put it on.<br />(I have my old watch for night time - it has a luminous dial; having a watch<br />blind you with a searchlight brightness everytime you move your arm, meant<br />it lasted about 2mins in bed). So - I am a "loyal" or eager person for<br />these devices.<br /><br />But the silly design means I forget to take it with me. That is worse<br />than forgetting your phone; if you leave your phone at home, you know<br />it very quickly into your work day. So you just dont do it. But,<br />leaving the watch behind - well, sorry, but that is flawed marketing.<br /><br />All because it cannot last 24h of use.<br /><br />The new Android range from LG, Samsung and Motorola look great - options<br />at reasonable prices with high spec hardware (although varying screen<br />resolutions). I see many complain of the price (which is lower than<br />the silly extortionate price Samsung wanted when the Gear 1 originally<br />came out).<br /><br />Oh well...<br /><br />I see Apple are finally going to come out with a phone with 128GB of<br />storage! Yippee! I waited 5+y for that to happen, and now I can have<br />144GB or 160GB of flash at less than half the price Apple will charge for<br />their device. I think Apple missed the boat.<br /><br />It is very relaxing to use Android and use a variety of mechanisms to<br />copy files to the devices, vs the sole use of iTunes. And even in iOS 7,<br />the video player looks to be written by a child - totally unusable;<br />totally ignoring playlists; a horrible interface for deleting videos.<br />Unrecognizable icons.<br /><br />I fear that computing has now peaked. The new generation of software<br />is rapidly worse than the prior releases of software, simply because<br />"change is good".<br /><br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.32a-b6748<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-64720268473545640222014-06-04T15:29:00.001-07:002014-06-04T15:29:36.356-07:00Corrections...I wrote the other day that I had solved the silly "Cannot run gmail in firefox<br />cookie problem". Alas, I was wrong. I have to give credit to google here.<br />There is no way that they would allow this problem to be fixed or fixable<br />or provide a useful or informative message about the true problem.<br /><br />I believe I know the true problem, and I am really impressed how<br />such a technically gifted company can do this to their users. Well done<br />Google.<br /><br />On another correction or update note. I asked about<br />how many function calls vs function exits exist in any program, and<br />how they are not even close to the same. I mentioned that inlining<br />can confuse the scenario - this is true. But equally, tail-function<br />calls which get optimised into JMP instructions account for a potentially<br />large bulk of the deficit. It would be possible to unoptimise the tail<br />calls to get more accurate accounting, but I am not so bothered at present.<br />It is a problem that needs solving to create accurate and bounded<br />stack traces of an application.<br /><br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.32a-b6738<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-88783093881587120112014-05-31T15:20:00.001-07:002014-05-31T15:20:36.730-07:00Metrics, Statistics and Code QualityI've been toying with writing a code coverage tool - similar<br />to cov/gcov, but different. Its based on a piece of work I did a long<br />time ago - at the time, this was a debugger, but in playing with<br />the concept, and being surrounded by many good tools and scripting<br />languages, something "new" starts to appear.<br /><br />The discussion below is about C/C++ - the results may not<br />be applicable for Java/.NET, Python/Perl.<br /><br />Consider the following question: For your favorite application,<br />how many functions are called to start the application?<br /><br />You can guess at the answer if you dont know the answer.<br /><br />Follow up question: How many function *returns* do you estimate<br />happen during the program startup?<br /><br />You are wrong! The number of function returns may not equal<br />(to a close approximation) the number of function calls.<br /><br />I was surprised by this observation. I tested the 'cr' console<br />mode CRiSP startup. It runs about at about 550,000 function calls<br />to start it up. But, surprisingly, only about 447,000 function returns.<br /><br />The reason is: inlining. An inlined function may show up<br />as a function entry, but may not show as a function returning.<br /><br />Once we have a trace of the function executions, the possibilities<br />open up to all sorts of metrics generation.<br /><br />We can look at the frequency - which functions are called the<br />most. Or we can look at duration. Duration can be problematic<br />for those functions which are called once, but never return (eg.<br />"main" will get called once, but wont return until the application<br />exits - or, maybe never, because exit() may be called).<br /><br />The tracing tool I have logs every function call, line executed, and<br />function return, for offline analysis. Execution of CRiSP generates<br />a 500MB log file - quite hefty for a 'small' application.<br /><br />Theres some other things that can easily be done here - such<br />as instrumenting certain instructions or functions to gain an insight<br />into other things. For example, it would be possible to trace<br />all mutex locks, or file I/O, or log the stack of specific scenarios.<br /><br />Much of this may sound familiar, because gcov, strace and dtrace can do<br />variants of these. The point being that each tool excels at a specific<br />domain of monitoring, but almost none give you programmatic access<br />to detailed working of an app. dtrace comes close, with the D scripting<br />language, but its not really very good for user space introspection<br />(other than trapping function calls and stack traces).<br /><br />If theres interest, I will publish the tool - its a simple Perl<br />script for the annotation recording, and a small C library. The tool<br />modifies the assembler code of your application (so you really need a<br />special area to build in - you dont want to test or distribute these<br />binaries, since there is a size and speed penalty to this optimisation;<br />I havent finished optimising - the execution penalty when the tracing<br />is disabled is small, but not small enough).<br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.32a-b6738<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0tag:blogger.com,1999:blog-8336326562741944626.post-53315028370961990692014-05-31T10:28:00.001-07:002014-05-31T10:28:21.764-07:00GMail cookie problem - SOLVEDAfter months of issues with logging into gmail from firefox, I have<br />finally found what was causing the problem. This problem<br />is prominent across the web, yet nobody has seemed to find a solution.<br /><br />The problem shows itself by trying to get to gmail, and being thrown<br />a "Your browser has cookies turned off" dialog. Its very infuriating, since<br />cookies are not off, and the dialog is not informative as to the true<br />problem - hence taking months to resolve (for me).<br /><br />A partial solution was to delete all google cookies. It seems like<br />the issue is related to google-chat - something I never use, but gmail <br />insists on putting up the gchat login underneath the mailboxes.<br /><br />I decided to turn that off, and the problem goes away ! If<br />I restart firefox, I can get to my two tabs for my different mail<br />accounts, and the inbox shows fine, and I can browse/send mail.<br /><br />The only strangeness is that Gmail displays a <br /><br /><pre><br />Gmail is having authentication problems. Some features may not work. Try logging in to fix the problem.<br /></pre><br /><br />Damned if I am going to do that. Maybe if the error message was<br />clear about what the issue is, then I might do the login trick.<br /><br />But I am very mistrusting of the quality of gmail. Maybe, by<br />disabling gchat, my firefox wont bloat so much.<br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.32a-b6738<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com1tag:blogger.com,1999:blog-8336326562741944626.post-11457738404143371122014-05-31T04:47:00.001-07:002014-05-31T04:47:11.286-07:00Please leave my source alone! bug in gcc - yes - a real one!After adding hyperlink detection to my terminal emulator, I started seeing<br />strange problems in fcterm. fcterm is the terminal emulator - it has many features,<br />and works well with 'cr' - the character mode version of CRiSP.<br /><br />I added hyperlink detection the other day, because I was bored. (I need<br />to implement hyperlink clicking, next).<br /><br />I was having problems with my Ubuntu 14.04 - the cpus had been spinning for<br />many days due to issues with khubd kernel process. After the reboot, I was<br />running the new fcterm. But ALT key processing was broken. Weird.<br /><br />After investigation, it turns out that gcc wants to convert strcpy() calls<br />into stpcpy() calls. Ok, that may be fair.<br /><br /><br />Heres the source code:<br /><br /><pre><br /> strcpy(rp, keymapping[k].k_value);<br /></pre><br /><br />Heres the assembler:<br /><br /><pre><br /> .loc 1 1918 0<br /> movq %r15, %rsi<br /> movq %r12, %rdi<br /> call stpcpy<br /></pre><br /><br />Why is it converting strcpy to stpcpy ? Because its trying to be clever. stpcpy is like strcpy,<br />but returns the end of the copied string, not the start.<br /><br />Unfortunately, this version of glibc seems to be broken. strcpy and stpcpy - at best, will do<br />a single strlen() over the src argument. Heres the disassembly.<br /><br /><pre><br />disass stpcpy<br />Dump of assembler code for function stpcpy:<br /> 0x0000000000427150 <+0>: push %r12<br /> 0x0000000000427152 <+2>: mov %rsi,%r12<br /> 0x0000000000427155 <+5>: push %rbp<br /> 0x0000000000427156 <+6>: mov %rdi,%rbp<br /> 0x0000000000427159 <+9>: mov %rsi,%rdi<br /> 0x000000000042715c <+12>: push %rbx<br /> 0x000000000042715d <+13>: callq 0x404ff0 <strlen@plt><br /> 0x0000000000427162 <+18>: mov %rbp,%rdi<br /> 0x0000000000427165 <+21>: mov %rax,%rbx<br /> 0x0000000000427168 <+24>: callq 0x404ff0 <strlen@plt><br /> 0x000000000042716d <+29>: lea 0x1(%rbx),%edx<br /> 0x0000000000427170 <+32>: add %rax,%rbp<br /> 0x0000000000427173 <+35>: mov %r12,%rsi<br /> 0x0000000000427176 <+38>: mov %rbp,%rdi<br /> 0x0000000000427179 <+41>: movslq %ebx,%rbx<br /> 0x000000000042717c <+44>: movslq %edx,%rdx<br /> 0x000000000042717f <+47>: callq 0x405440 <memcpy@plt><br /> 0x0000000000427184 <+52>: lea 0x0(%rbp,%rbx,1),%rax<br /> 0x0000000000427189 <+57>: pop %rbx<br /> 0x000000000042718a <+58>: pop %rbp<br /> 0x000000000042718b <+59>: pop %r12<br /> 0x000000000042718d <+61>: retq<br />End of assembler dump.<br /></pre><br /><br />See the two calls to strlen? I believe that to be the problem. Now I need to stop strcpy being converted<br />to stpcpy (which is not easy - there is a gcc compiler option to do this, but now I would have to sprinkle<br />this everywhere - for all build tools). Worse, I now know there is a rogue stpcpy on other peoples systems,<br />so CRiSP could be affected if they download my binaries.<br /><br />I havent suffered a compiler bug in nearly 20y - exactly because my coding style and idioms is trained<br />to avoid complex stuff, and the compilers have become more reliable. But now, that seems to be at an<br />end.<br /><br /><br /><span class='post-comment-link'><br />Post created by CRiSP v11.0.32a-b6738<br /></span><br /><br />Paul Foxhttp://www.blogger.com/profile/11969759101059066480noreply@blogger.com0