All pastes #617922 Raw Edit

Untitled

public text v1 · immutable
·published 2007-07-13 16:08 UTC
rendered paste body
art> why glibc-2.5-18.fc6.src.rpm has been updated for FC-6 ? i'm experiencing a backtrace using my video steaming player...
* k0k (n=k0k@fedora/k0k) a rejoint #fedora-devel
<kwizart> http://pastebin.ca/617903
<kwizart> hum started a new terminal and it works fine...(only Xlib: unexpected async reply (sequence 0xb)! )
<pjones> kwizart: that says, essentially, one of "vlc called munmap() twice on the same address" or "vlc called munmap() on an address it never got as a result from mmap()"
<pjones> (which may or may not be vlc's fault, given the call trace...)
* ensc est parti (Nick collision from services.)
<pjones> I'm not going to ask why it mmap()'d /dev/zero
* ensc (n=irc-ensc@fedora/ensc) a rejoint #fedora-devel
<jima> everyone could use a little zero
<joe> skvidal: ping
* nirik points out that the zero effect was a pretty good movie... 
<kwizart> pjones, i will ask upstream but i also have problem with gethostbyname with vlc... vlc needs iptable to be disabled to access it on F-7 (and only F-7)
 paragn pcheung pingou pinhighwedge pjones poelcat pp_ 
<jima> nirik: never seen it :|
<kwizart> thx  for the tips...
<pjones> yeah, just wondering what point it could possibly serve.  Pretty sure bzero(addr, n) is going to be faster than memcpy(foo, devzero_address,n) by a very, very large margin.
<pjones> (considering the latter involves a context switch and the former does not...)
<pjones> hrm.  maybe not a context switch, dunno how mmap on /dev/zero is actually implemented.  but certainly at least a page fault and kernel entry.