[FFmpeg-devel-irc] IRC log for 2010-04-24

[irc at mansr.com]

[01:36:45] <mru> Dark_Shikari: doubtful
[01:36:59] <mru> iphone forces you to do yuv to rgb conversion in software
[01:37:06] <mru> even though the hardware is perfectly capable
[01:39:33] <RTFM_FTW> umm you don't need to do YUV -> RGB in SW
[01:39:48] <RTFM_FTW> you could trivially use the ES1 GL path for this
[01:39:56] <RTFM_FTW> which I did :)
[01:40:26] <RTFM_FTW> in fact *everything* outside of the initial decode could be handled through 3D HW
[01:40:43] <RTFM_FTW> even with fixed function ES1 level HW
[01:40:49] <mru> the old iphone has some private apis that let you do it efficiently
[01:40:55] <mru> those are gone on 3gs
[01:41:09] <mru> and you were never allowed to use them
[01:41:11] <RTFM_FTW> again you don't need private APIs either
[05:43:05] <Dark_Shikari> mru: so if you had hardware for yuv->rgb
[05:43:06] <Dark_Shikari> could you do it?
[05:43:10] <Dark_Shikari> i.e. given the lack of simd and all that
[05:48:32] * pJok waits for Apple to buy ARM and then pull the IP from the market
[05:48:46] <pJok> that would be hillarious
[05:49:37] <astrange> RTFM_FTW has done it with gl fixed-function, i haven't seen the video bitrate he used (or how accurate the display was)
[05:50:13] <Dark_Shikari> pJok: the merger wouldn't be approved
[05:51:36] <pJok> Dark_Shikari, would still be hillarious if it actually would get approved
[05:54:02] <pJok> Apple could single handedly ruin ARM
[06:02:45] <_av500_> they will also impose lifetime limit on ARM cpus you can buy!
[06:03:04] <_av500_> sorry, no more washing machine
[06:09:31] <Yuvi> Dark_Shikari: borderline, ffmpeg decodes a 480x320 baseline encoded by x264 --tune fastdecode --subme 0 --bitrate 1500 decodes at 23 fps
[06:09:55] <Dark_Shikari> how much do you think could be gained via armv6 asm?
[06:11:08] <Dark_Shikari> I've seen SWAR implementations of hpel MC
[06:11:08] <Yuvi> no clue, I'd doubt more than 10-20% at the really high end
[06:11:25] <Dark_Shikari> well I would assume you could probably double the speed of idct
[06:11:32] <Dark_Shikari> and speed up mc copy a lot
[06:12:10] <Yuvi> mc 0,0 is already optimized iirc
[06:12:15] <Dark_Shikari> ah, true.
[06:12:27] <Dark_Shikari> That does seem odd though.  3g is not MASSIVELY slower than 3gs when one ignores lack of neon
[06:12:44] <Dark_Shikari> and at subme 0, there's nearly no simd-requiring stuff
[06:12:48] <Dark_Shikari> just idct really
[06:12:53] <Yuvi> no dual issue, 416 vs. 533 MHz
[06:12:59] <Dark_Shikari> oh wow, it's only 416mhz?
[06:13:03] <Dark_Shikari> so it's not even a fast arm11
[06:13:55] <Yuvi> or did the 3gs get up to 600
[06:15:28] <Yuvi> internet says it does
[06:17:04] <Dark_Shikari> hmm, ok
[06:17:21] <Dark_Shikari> maybe if they're interested in optimizing for it, I can get some money =p
[06:17:46] <Dark_Shikari> I suspect there may be a lot of opportunities like this in the future, e.g. optimizing for specific hardware targets
[06:17:49] <Dark_Shikari> Oh, and they also care about the xbox 360
[06:17:58] <Dark_Shikari> which is apparently too slow to do 720p h264 in a single thread
[06:29:51] <pJok> _av500_, i thought washing machines mainly used freescale/nec mcu's or 8051 clones
[08:30:36] <_av500_> pJok: not the iWash
[08:41:46] <pentanol> hi mru, at this weekend you here?
[08:41:50] <pentanol> here kind of tiny ffmpeg http://codepad.org/UXO06Dsq
[08:51:37] <pentanol> nop, in first not full,  there devided http://codepad.org/ZwudRruj  http://codepad.org/Q61vrhyM http://codepad.org/XGz2XvZD
[09:05:08] <_av500_> pentanol: your main() does nothing?
[09:14:42] <pentanol> no it tries allocate everything necessary... avcodec_alloc_context2 but got a segfault
[09:16:06] <_av500_> why are you doing this at all?
[09:16:28] <pentanol> perhaps I got this because....  http://codepad.org/00E1U4qK
[09:16:43] <pentanol> actually it won't work on my arm uC lib
[09:17:05] <pentanol> but it compiled well and then static linked well too
[09:19:28] <pentanol> llrint and log does into libm, but compiled doesn't see that
[09:27:09] <pentanol> so when I've compiled this static, I obtains  http://codepad.org/w6oo0Uu5
[09:31:24] <pentanol> here disasm this elf for arm ... http://download255.mediafire.com/aev5gvpe2YDg/fznjtemntly/ffmpeg_tiny.asm.tar.bz2
[09:40:04] <pentanol> it crashed everytime when dst= ((uint8_t*)obj) + o->offset; ofset equals 184
[09:57:52] <pentanol> odd it crashes when hits { "iba",  184 }
[09:58:21] <mru> pentanol: please try to remove as much as possible
[09:58:33] <mru> I expect you to end up with no more than a page
[09:58:55] <mru> throw in some printfs so you can trace the code flow
[09:58:56] <pentanol> yes, but I can remove
[09:59:06] <mru> remove any code that isn't executed before it crashes
[09:59:06] <pentanol> because then I can't compiel it
[10:15:00] <CIA-7> ffmpeg: stefano * r22958 /trunk/doc/libavfilter.texi:
[10:15:00] <CIA-7> ffmpeg: Consistently prefer @var{VAR} over ``VAR'' for indicating filter
[10:15:00] <CIA-7> ffmpeg: parameters.
[10:40:15] <CIA-7> ffmpeg: stefano * r22959 /trunk/ffserver.c: Statically initialize ffserver.c:config_filename, simplify.
[10:40:15] <CIA-7> ffmpeg: stefano * r22960 /trunk/ffserver.c:
[10:40:15] <CIA-7> ffmpeg: Implement ffserver.c:report_config_error() and a macro for logging
[10:40:15] <CIA-7> ffmpeg: error messages / updating the error count.
[10:41:41] <pentanol> mru here disasm and snippet http://download784.mediafire.com/idsqgymgbgTg/yutzmytjodt/ffmpeg_tiny.asm1.tar.bz2 http://codepad.org/VPcbKPYw
[11:15:47] <mru> I said you should be able to reduce it to one page of code
[12:06:01] <jai> seriously, how many people use ffmpeg on beos?
[12:06:06] <jai> i know one :)
[12:06:15] * mru knows none
[12:06:30] <mru> if mmu_man used it, he'd keep it from breaking
[12:06:53] <jai> mmu_man probably has a box somewhere which runs it
[12:07:38] <DonDiego> hmm
[12:07:45] <DonDiego> fate looks good except for ia64
[12:08:04] <mru> sparc/linux is dead again
[12:08:52] <saste> DonDiego: how is the 0.6 release thing going on?
[12:10:02] <DonDiego> /misc/samples/mphq/fate-suite/lossless-audio/inside.tta: Operation not permitted
[12:10:10] <DonDiego> mru: permission problem on your avr fate box?
[12:10:22] <DonDiego> saste: that's what we're talking about right now :)
[12:10:34] <DonDiego> bbl
[12:13:01] <mru> DonDiego: compiler bug
[13:15:45] <pentanol> hm, I got why it segfault happens on my arm, if I delete everything from static const AVOption options[]={ , but leave just one tiny tool works well without segfault
[13:44:42] <nfl> DonDiego, I need your  public key
[13:44:54] <mru> it should be on keyservers
[13:45:02] <mru> fingerprint is in MAINTAINERS
[14:00:40] <jai> bleh, maybe we can stop using the soc repo ;)
[14:01:11] <mru> git ftw
[14:01:38] <jai> indeed, and with all those free git services around
[14:14:05] <nfl> DonDiego, I've sent you a request for soc repo access
[14:21:48] <jai> why not just host your soc code on github?
[14:21:54] <jai> nfl: ^
[14:22:23] <merbanan> nfl: if you can provide commit messages to the soc mailinglist you can use whatever you prefer
[16:17:22] <RTFM_FTW> astrange I was fooling around with (700k) WMV2 content...
[16:18:04] <RTFM_FTW> rendering this into a 5:6:5 display was "meh" concerning quality... 8:8:8:8 (as one would expect) is far better
[16:18:22] <RTFM_FTW> its also considerably slower on older (MBX level) HW tho
[17:26:37] <_av500_> 565 is meh
[17:32:53] <RTFM_FTW> 5:6:5 is ideal when it comes to saving on render bandwidth
[17:33:15] <RTFM_FTW> streaming updates (and streaming RTT) aren't cheap operations
[17:33:31] <RTFM_FTW> at least on older, highly limited HW
[17:47:57] <BBB> did kshishkov come online today?
[17:49:29] <janneg> BBB: no, is he supposed to be back?
[17:49:35] <BBB> dunno
[17:49:40] <BBB> wanted to ask him some vc1-related questions
[18:53:21] <twnqx> mh this sucks
[18:53:36] <twnqx> uname() is one of the things you can't hook in libc calls?
[18:53:56] <twnqx> i hate writing strace() hooks :X
[19:51:50] <ShadowJK> I guess the call gets inlined?
[20:00:51] <BastyCDGS> good evening to all :)
[20:01:45] <jai> twnqx: do you mean ld_preload'ing a custom uname doesn't work?
[20:01:56] <twnqx> jai: excatly.
[20:02:19] <twnqx> works for programs i compiled here, but not for two commercial apps
[20:02:23] <BastyCDGS> puh that was a day today...
[20:02:36] <BastyCDGS> had to fix wires from the power supply of my laptop
[20:02:55] <BastyCDGS> they were almost broken, but luckily I got fixing it...
[20:03:50] <jai> twnqx: what exactly is the error?
[20:04:08] <twnqx> sefault.
[20:04:11] <twnqx> segfault*
[20:04:55] <twnqx> even when i don't touch the values at all
[20:05:19] <jai> twnqx: hmm, is libpthread involved
[20:05:32] <twnqx> likely
[20:05:43] <twnqx> but i don't have local variables, so it would be reentrant
[20:05:56] <jai> twnqx: http://sourceware.org/ml/libc-hacker/2010-04/msg00001.html
[20:06:16] <jai> could be related
[20:06:33] <twnqx> uhhh
[20:06:35] <twnqx> hm
[20:06:56] <twnqx> could be, if that init is called before i have time to ldopen glibc...
[20:07:07] <jai> yes
[20:07:10] <jai> exactly
[20:07:22] <twnqx> easy to verify
[20:07:47] <twnqx> (although my ptrace-based syscall hooker is almost finished now)
[20:08:10] <BastyCDGS> btw, I have a strange problem with ffmpeg today...
[20:08:16] <BastyCDGS> it doesn't anymore find the IFF loader
[20:08:23] <twnqx> but some of the stack unwinds are weird...
[20:08:38] <BastyCDGS> even for ASH.LBM it says couldn't find a suitable loader
[20:09:44] <BastyCDGS> I try a complete reset, i.e. a clean git checkout again
[20:09:45] <twnqx> jai: http://nopaste.info/c79135d39c.html maybe the first is the pthreads one...
[20:09:51] <BastyCDGS> maybe I broke something accidentally
[20:12:08] <twnqx> though.. maybe my stack unwinder fails
[20:12:37] <jai> twnqx: why this whole exercise btw ;)
[20:13:05] <twnqx> because the stupid thing refuse to talk to my jtag programmer
[20:13:32] <twnqx> Cable operation is not supported when running the 32-bit version of the application on a 64-bit platform.
[20:13:32] <jai> oh
[20:14:05] <twnqx> hence... *you run on a 32-bit platform*
[20:14:19] <twnqx> and i had most of the code around anyway :P
[20:14:27] <twnqx> from some... other exercises
[20:16:34] <jai> heh
[20:16:49] <twnqx> not touched in two years, but even the vdso code is still correctly recognized
[20:27:42] <twnqx> jai: you're right
[20:27:58] <twnqx> uname is called before i got to load glibc...
[20:27:59] <twnqx> hm
[20:29:05] <BastyCDGS> does change of the link libs order help here twnqx?
[20:29:15] <BastyCDGS> and/or object files?
[20:29:48] <twnqx> since the original program isn't by me i can't change :P
[20:30:28] <twnqx> hm, calling dlopen() and friends while being called from libpthreads _init seems not to work
[20:32:02] <BastyCDGS> does you call it from a launched thread there?
[20:32:07] <twnqx> weird, still crashes
[20:32:16] <twnqx> ah well
[20:32:19] <BastyCDGS> as far as I know you can't call dlopen like stuff from a thread, you have to use main thread
[20:32:20] <twnqx> gonna ignore that.
[20:32:45] <twnqx> i'm called from libpthreads _init it seems
[20:32:51] <twnqx> before pthreads are even started
[20:33:08] <twnqx> anyway, the ptrace method is just more code.
[20:33:36] <BastyCDGS> had once a similar problem with wxwidgets wanted to open and init a socket from a non-main thread
[20:33:41] <jai> twnqx: maybe apply that patch and use that custom glibc build :)
[20:33:41] <BastyCDGS> caused all sort of strange stuff
[20:34:32] <twnqx> BastyCDGS: i once wrote code that would spawn thrades to asynchronously handle sockets using signals
[20:34:46] <twnqx> it was fun to learn how to do that
[20:34:49] <BastyCDGS> moving the socket open/init stuff to main thread and then reading/writing socket from the sub-thread then worked well
[20:34:52] <twnqx> until someone ran it on debian.
[20:35:02] <twnqx> without NPTL.
[20:35:17] <twnqx> and you had no ideas which thread would actually receive the signals >_>
[20:35:33] <jai> hah!
[20:36:55] <BastyCDGS> it's always a good idea to read docs when using multithreaded stuff if the libs you're using are thread-safe...
[20:36:58] <jai> twnqx: anyhow, if you have time try the patched build, it should pretty much work
[20:37:07] <twnqx> too lazy
[20:37:07] <BastyCDGS> there's still many stuff out there which isn't thread-safe
[20:37:16] <twnqx> and also, i want it more universal :P
[20:37:39] <twnqx> also, i could just implement uname() by reading from /proc, or even by doing the syscall myself
[20:38:00] <jai> twnqx: well, the uname call on init should be in glibc's private namespace
[20:38:16] <jai> twnqx: but drepper refused it :/
[20:38:23] <twnqx> > drepper
[20:39:29] <jai> twnqx: yeah, you'd probably dlsym it from libc, call it, overwrite machine/whatever and returnb
[20:39:45] <twnqx> that's what i tried :)
[20:40:16] <jai> in an ideal world it would work pretty well too :)
[20:40:29] <twnqx> worked for all functions i tried so far :P
[20:40:47] <twnqx> uh what
[20:40:56] <BastyCDGS> ehm
[20:40:57] <twnqx> something's broken now...
[20:41:11] <twnqx> when i change it, the app doesn't even start
[20:41:14] <BastyCDGS> just was looking your nopaste stuff
[20:41:26] <BastyCDGS> it seems you try to call an x86_64 func from x86_32...
[20:41:35] <BastyCDGS> that doesn't work without a wrapper, maybe that is the cause?
[20:41:38] <twnqx> mh?
[20:41:41] <twnqx> nah
[20:41:50] <BastyCDGS> http://nopaste.info/c79135d39c.html
[20:41:58] <twnqx> it won't preload to a 64bit anyway
[20:42:08] <twnqx> itÄs a 32bit lib in that side of the show
[20:42:24] <BastyCDGS> uname(): x86_64 from
[20:42:35] <BastyCDGS> it seems to call uname x86_64 from a lib32
[20:42:35] <twnqx> yeah.. that's what the kernel replies back
[20:43:08] <twnqx> grrr so if i pretend this machine is i686 the app just terminates
[20:44:52] <twnqx> so i have to change the reply on a certain call only *sigh*
[20:44:56] <jai> twnqx: time for plan b? :)
[20:46:34] <twnqx> jai: not yet
[20:46:54] <twnqx> does strcpy copy the final 0 as well?
[20:47:03] <BastyCDGS> yes
[20:47:24] <twnqx> so that's not the mistake.
[20:49:15] <BastyCDGS> I think strcpy internally counts number of characters until \0 and then does a memcpy
[20:49:45] <twnqx> yeah, quick testprogram confirms correct operation
[20:51:56] <jai> BastyCDGS: not the libc implementation atleast
[20:52:17] <BastyCDGS> does it call an intrinsic asm func instead?
[20:52:26] <BastyCDGS> a rep movsb loop or sth like that?
[20:52:43] <jai> BastyCDGS: no, just a plain old do-while
[20:53:11] <jai> with some bounds checking on the src pointer after the copy
[20:54:07] <BastyCDGS> btw, anyone checked out my optimization link from yesterday
[20:54:18] <BastyCDGS> this guy has very optimized memcpy, strcpy, malloc, etc. stuff
[20:54:23] <BastyCDGS> malloc uses mem pooling etc.
[20:54:28] <BastyCDGS> might be of interest for ffmpeg ;)
[20:56:28] <BastyCDGS> twqnx, could you explain me a bit what you want to do with uname anyway?
[20:56:35] <BastyCDGS> I did miss the start of your discussion
[20:56:44] <twnqx> i want the program to believe it runs on i686
[20:56:54] <twnqx> (it's a 32bit app anyway)
[20:57:01] <BastyCDGS> why that is necessary?
[20:57:22] <twnqx> it refuses to what it is supposed to on x86_64
[20:57:56] <twnqx> and the culplrit why it's not working... is apparently the compat libx11
[20:58:12] <twnqx> so... i need to modify my stack unwinder
[20:58:16] <twnqx> sucks.
[20:58:39] <BastyCDGS> what does your stack unwinder do exactly?
[20:58:56] <twnqx> figure out from where the calls originate
[20:58:59] <BastyCDGS> I assume you're dealing with plain C in the whole space?
[20:59:07] <twnqx> ummmm...
[20:59:20] <BastyCDGS> if there's C++ involved you have also to unwind exceptions
[20:59:27] <twnqx> ah that you mean
[20:59:35] <twnqx> i don't really care
[20:59:52] <twnqx> but C++ might explain the [stack] hops
[21:00:00] <twnqx> in the backtraces on the pastebin
[21:00:11] <BastyCDGS> exceptions have to be unwinded even if you don't use them
[21:00:26] <twnqx> i'm unwinding from an assembler perspective
[21:00:39] <twnqx> i don't care where it jumped true
[21:00:42] <twnqx> through*
[21:01:02] <twnqx> i gues longjmp() would break it
[21:01:13] <BastyCDGS> that's possible, too.
[21:01:21] <twnqx> exceptions shouldn't
[21:01:34] <twnqx> it just reads the stack
[21:02:22] <BastyCDGS> not 100% sure about this if exceptions are also on the stack, if in doubt try the C++ stuff compile with -fno-exceptions -fno-rtti
[21:02:36] <twnqx> i can't compile this
[21:02:41] <BastyCDGS> oh
[21:02:43] <twnqx> if i could compile it
[21:02:44] <BastyCDGS> closed source?
[21:02:58] <twnqx> why else would i try to modify the behavior from the outside...
[21:03:34] <BastyCDGS> that's right...but could be a learning exercise ;)
[21:04:26] <twnqx> it for sure contains Cüü
[21:04:28] <twnqx> C++
[21:04:39] <twnqx> since it has libQt and friends
[21:04:53] <BastyCDGS> if it uses Qt then it's 100% C++ ;)
[21:05:23] <BastyCDGS> maybe you find some infos regarding this with a hexdump of the executable
[21:05:33] <twnqx> boring
[21:05:33] <BastyCDGS> a lot of compilers put their signature there
[21:05:42] <twnqx> i have no intention of even looking at it
[21:05:50] <twnqx> i just want it to work :P
[21:05:54] <BastyCDGS> if they compiled with exceptions you have to deal with them I'm afraid off
[21:06:05] <twnqx> shouldn't matter at all
[21:06:12] <twnqx> they'll just be on the stack
[21:07:32] <BastyCDGS> I'll do a search on this one moment
[21:10:16] <BastyCDGS> the thing is that you can't mix code with -fno-exceptions and code with -fexceptions
[21:10:22] <BastyCDGS> even within g++
[21:10:32] <BastyCDGS> so they both interfere somehow
[21:11:41] <BastyCDGS> maybe the compiled code also uses -ffast-call
[21:12:06] <BastyCDGS> which pushes first two function args in regs instead on stack on x86_32
[21:13:22] <BastyCDGS> http://stackoverflow.com/questions/490773/how-is-the-c-exception-handling-runtime-implemented
[21:14:32] <BastyCDGS> btw, another idea to solve your problem
[21:14:48] <BastyCDGS> do you have an x86_64 with virtualization support (patricia etc.)?
[21:15:01] <BastyCDGS> maybe you can use this to make your app thinking it's a x86_32
[21:15:35] <BastyCDGS> this even allows faking CPUID to return a different string
[21:15:40] <BastyCDGS> vendor id etc.
[21:17:42] <twnqx> hm
[21:17:54] <twnqx> i wonder if it *does* cpuid
[21:18:03] <twnqx> where's my single stepper...
[21:19:14] <BastyCDGS> btw, just looking at your nopaste stuff again, I see 4x [stack] instead of a func name
[21:19:22] <BastyCDGS> this could be the exception stuff
[21:20:20] <BastyCDGS> at least try to find out which compiler they we're using...
[21:21:03] <BastyCDGS> btw, if you're single stepping find the position where it wants to call uname and replace this with a series of NOPs ;)
[21:32:11] <twnqx> i could just dynamically scan the program's memory for the x86_64 string and replace it with x86_65
[21:33:06] <BastyCDGS> would be possible, too...
[21:34:42] <BastyCDGS> don't forget that the string might be wchar_t
[21:35:10] <BastyCDGS> to check for x\08\06\0_\06\04
[21:35:12] <BastyCDGS> so
[21:42:11] <twnqx> processtools.c:170: error: generating trampoline in object (requires executable stack)
[21:42:12] <twnqx> O_O
[21:42:25] <twnqx> now that's a gcc error i never saw before
[21:42:39] <BastyCDGS> I see this error now for the 1st time, too ;)
[21:42:56] <BastyCDGS> what did you change that this error occurs?
[21:43:37] <twnqx> i... moved a function which is a parameter for another function into a third function
[21:44:13] <twnqx> http://nopaste.info/0f3e44a760.html
[21:46:16] <BastyCDGS> hmm if remembering correct you can't do this...
[21:47:01] <twnqx> oh, you can
[21:47:07] <twnqx> just not with -Wall -Werror :P
[21:48:38] <BastyCDGS> I mean it violates the standard and it seems that gcc gets confused when you do it anyway
[21:49:09] <twnqx> processtools.c:170: warning: generating trampoline in object (requires executable stack) - jo it just generates a trampoline (and a warning)
[21:49:47] <BastyCDGS> is there any specific reason you want it inside a function?
[21:50:09] <twnqx> i want another version of it that needs access to the outer function's parameters
[21:50:54] <BastyCDGS> and this really works this way?
[21:51:12] <BastyCDGS> why not use just global vars for testing?
[21:51:32] <twnqx> because then i have globals vars in the final too :(
[21:51:45] <twnqx> and yes, works.
[21:52:20] <twnqx> i could just pass a void pointer to the unwind, and make it pass the same to the callback
[22:08:46] <twnqx> wow, changing the return "sometimes" causes heisenbugs
[22:09:12] <BastyCDGS> quantum physics bugs :D
[22:09:23] <twnqx> i just had a heap corruption
[22:10:19] <BastyCDGS> btw, there is a language out here which mimics QM that means the code does change by random factors and thus does everything sth. else
[22:10:58] <twnqx> hm i wonder how making a child sleep via ptrace and threads interact
[22:11:37] <BastyCDGS> you mean sending/receiving signal messages?
[22:11:53] <twnqx> well... blocking it on syscall
[22:13:43] <BastyCDGS> http://kerneltrap.org/index.php?q=mailarchive/freebsd-hackers/2007/3/31/219640/thread
[22:13:54] <BastyCDGS> look at the post from w0rm
[22:29:05] <twnqx> meh
[22:30:42] <BastyCDGS> did that help a bit?
[22:34:54] <twnqx> not yet
[22:35:52] <twnqx> i just realized that the application apparently loads more libs during runtime
[22:36:40] <twnqx> and possibly doesn't use the uname output at all
[22:37:39] <BastyCDGS> so CPUID?
[22:38:24] <BastyCDGS> maybe it's really the best way to use the newer CPU virtualization functions to get this working
[22:38:33] <twnqx> it even opens the library that has the error messgae dialog only after the tenth or so  uname call
[22:38:45] <BastyCDGS> I have no experience regarding coding this but maybe a look into VirtualBox src helps a bit
[22:38:48] <BastyCDGS> qemu
[22:52:30] <twnqx> funny
[22:52:34] <twnqx> in console mode it works
[22:52:46] <twnqx>  OS platform = i686.
[22:52:46] <twnqx> #
[22:53:06] <twnqx> so yeah, it uses uname, and if you change it, sometimes it crashes.
[22:53:33] <twnqx> tha wouldn't all be so bad
[22:53:37] <BastyCDGS> sometimes? that means it basically works with x86_64?
[22:54:02] <twnqx> it totally works with x86_64, just actively denies me the functionality i want
[22:54:24] <BastyCDGS> why did they implement then such a silly thing? if it works?
[22:54:30] <twnqx> well
[22:54:36] <twnqx> dunno it it works (yet)
[22:54:37] <BastyCDGS> do they want you buying an extra license for 64 bit?
[22:54:44] <twnqx> there's one thing:
[22:54:56] <twnqx> ERROR:iMPACT - Please update to WinDriver version 8.02 or later. See Answer Record 22648.
[22:55:02] <twnqx> (i am running version 10.1)
[22:55:05] <twnqx> <_<
[22:55:30] <twnqx> because the version they ship
[22:55:35] <twnqx> does not compile on 2.6.33
[22:55:49] <BastyCDGS> WinDriver???
[22:55:51] <twnqx> actually, even 10.1 doesn't
[22:56:07] <twnqx> unless you modify it slightly (just some checks for includes that moved around)
[22:56:35] <BastyCDGS> does it use windows drivers?
[22:56:40] <twnqx> apparently some kind of multi-os HAL
[22:57:05] <twnqx> i just had to totally rewrite their utterly wrong udev rules file
[22:57:28] <twnqx> now...
[22:57:43] <BastyCDGS> seems these guys have programmers there that just are able to install sth. like ubuntu ;)
[22:57:51] <twnqx> no
[22:57:58] <twnqx> sles.
[22:58:09] <twnqx> 9.0 it seems
[22:58:18] <twnqx> fuck it was more than painful on windows
[22:58:29] <twnqx> because the same bullshit checks exist "do not install on 64bit"
[22:58:44] <twnqx> then you run it in virtual xp mode (effectively a VM)
[22:58:56] <BastyCDGS> win7 virtual xp mode?
[22:58:56] <twnqx> and it doesn't work because "can't run in terminal server"
[22:58:59] <twnqx> yes
[22:59:20] <twnqx> so you can't run the app window only, but if you use the FULL VIRTUALIZED version it works
[23:00:35] <BastyCDGS> M$ could start with releasing only 64-bit versions of newer windows versions...I bet in just one week there's no x86_32 only software anymore ;)
[23:02:12] <twnqx> the funny thing is
[23:02:28] <twnqx> after it detects this driver
[23:02:51] <twnqx> and fails to use it because the latest version that is newer tahn the minimum is too old
[23:03:00] <twnqx> it recognizes x86_64 again
[23:04:52] <BastyCDGS> strange piece of software, really...
[23:05:43] <BastyCDGS> but what's the purpose of this tool after all?
[23:05:47] <BastyCDGS> what do you use it for?
[23:06:45] <twnqx> program the effing FPGAs from that vendor
[23:06:52] <twnqx> and
[23:06:56] <twnqx> i feel
[23:07:04] <twnqx> kinda annoyed, lookinf into my dmesg
[23:07:53] <twnqx> the crashes of this program, when i change the name
[23:07:57] <twnqx> of the machine
[23:08:04] <twnqx> segfault at 6d7c6d60 ip 000000006d7c6d60 sp 00000000ffeb6a0c error 14 in libnss_nis-2.11.so[f4d45000+9000]
[23:08:18] <twnqx> it crashes mostly... in libnss_nis
[23:08:32] <twnqx> also in libcups, or libXipc
[23:08:46] <BastyCDGS> does it call lib32 versions of it?
[23:08:50] <twnqx> has to
[23:08:54] <twnqx> it's all 32bit
[23:09:06] <twnqx> segfault at 56f556e1 ip 0000000056f556e1 sp 00000000ffeea2ec error 14 in 87f5e051180a7a75f16eb6fe7dbd3749-le32d4.cache-3[f4eeb000+6000]
[23:09:14] <twnqx> do i even want to know what it's doing...
[23:09:55] <BastyCDGS> ehm the stackpointer has an odd address
[23:10:03] <BastyCDGS> .....e1
[23:10:10] <twnqx> that's eip
[23:10:18] <BastyCDGS> oops right
[23:10:42] <twnqx> i BET their sizeof (struct utsname) differs from mine
[23:11:04] <BastyCDGS> probably due to alignment rules then
[23:11:08] <twnqx> and i'm overwriting their stack
[23:11:19] <twnqx> no, because that struct is chaos
[23:11:41] <twnqx> let's see what happens with more precide poking
[23:16:57] <twnqx> yes. of course. that was the cause of all the crashes.
[23:17:00] <twnqx> >_>
[23:17:17] * twnqx goes mad
[23:18:26] <BastyCDGS> 64-bit aligns different than 32-bit
[23:18:31] <twnqx> no
[23:18:36] <twnqx> the whole code runs in 32bit
[23:18:38] <twnqx> but
[23:18:52] <twnqx> there's an extension in gnu mode
[23:18:57] <twnqx> a fifth string
[23:19:08] <twnqx> i did not set gnu mode
[23:19:41] <twnqx> however, instead of grabbing the whole struct from the process' memory, modifying 5 bytes, and writing all of it back
[23:19:53] <twnqx> only writing the 5 bytes back makes it very well behaving.
[23:20:27] <BastyCDGS> that means much less crashes now?
[23:20:39] <twnqx> no crashes.
[23:21:34] <twnqx> good, i managed to solve 4 problems in getting this app to work so far
[23:21:34] <twnqx> >_>
[23:21:55] <BastyCDGS> that's fine...
[23:22:06] <twnqx> now for the last
[23:22:07] <BastyCDGS> hope that my assists helped you a bit though
[23:22:18] <twnqx> a version issue between two binary blobs
[23:33:21] <BastyCDGS> I'll go to bed now, very tired now
[23:33:39] <BastyCDGS> i wish you a good night and nice dreams and much success with fixing the last issue ;)
[23:55:24] <Dark_Shikari> how do I view the kernel syslog?