On Tue, Jul 1, 2008 at 4:40 PM, Jürgen Keil <[EMAIL PROTECTED]> wrote: > Dennis Clarke wrote: >> as I suspected .. a type casting problem. >> >> Looks like there is a fix and there is an engineer but the other bugid >> is not updated with the info. Or the two bugids are unrelated. Not >> likely .. that looks to be the issue right there. >> >> I'll try a build .. or .. no .. how the heck do I build a new kernel >> in OpenSolaris 200805 ? > > IIRC, you must use SXCE to compile the onnv-gate bits. > > I guess a quick hack is to use (x)emacs, edit the > 32-bit files /kernel/kmdb/genunix and /usr/lib/mdb/kvm/genunix.so > and overwrite the string "Free (freelist) %16llu" > with "Free (freelist) %16lu ". I've not tried this, but > I think it should work. Should mess up the alignment > because on 'l' is replace by a space, though. > > Maybe replace with "Free (freelist) %#16lu"...
ha .. we think alike. I was just looking at that and thinking that the printf function simply needs access to a string for format control and thus : -bash-3.2# strings /kernel/kmdb/genunix | grep freelist slab %p in cache %p freelist too long (%p) slab %p in cache %p freelist too short by %d Free (freelist) %16llu %16llu %3llu%% -bash-3.2# strings /usr/lib/mdb/kvm/genunix.so | grep freelist slab %p in cache %p freelist too long (%p) slab %p in cache %p freelist too short by %d Free (freelist) %16llu %16llu %3llu%% a change to the bytes in the "Free (freelist) %16llu %16llu %3llu%%" should result in the correct result. As a side note, and tangential to this discussion, I have long felt that we need a md5hash database in the system that would prevent this sort of hackery from taking place and making a change to a system state via some hacked up binary. Making a change to the kernel should be a strict no no .. but it is possible. Dennis _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
