***Server sets mode: +nt
***Glider_IRC_ is now known as Glider_IRC
<damo22>youpi: i meant "another time" as in I was going to sleep <damo22>youpi: heres a useful macro for kern/printf.h <damo22># define mach_printf(fmt, ...) printf(fmt, ##__VA_ARGS__) <damo22>but i think it only works for inside mach <damo22>youpi: ive dropped to db> from a mach deallocate, what do i look for? <damo22>0x01273580 in mach_msg_server_timeout () from /lib/i386-gnu/libc.so.0.3 <damo22>Single stepping until exit from function mach_msg_server_timeout, <damo22>which has no line number information. <damo22>Thread 24 received signal SIGTRAP, Trace/breakpoint trap. <damo22>223 *devp = ports_get_right (bd); <damo22>im getting 2904(outp) and 2804(inp) on port 108 <damo22>which causes the deallocation bug <damo22>i think im supposed to be using a MACH_MSG_TYPE_PORT_SEND_ONCE poly ***GeneralDuke1 is now known as GeneralDuke
<damo22>that fixed the spurious messages <damo22> *devp = ports_get_send_right (bd); <---- i dont know what needs to go here <damo22> *devicePoly = MACH_MSG_TYPE_PORT_SEND_ONCE; <youpi>to print the backtrace (both kernelland and userland) <youpi>msgh_id is the message number, see values in /usr/include/msgids <damo22>do i just put *devp = (device_t)(&bd->somemember); <youpi>using SEND_ONCE can't be correct <youpi>the port you return needs to be used several times <youpi>so it'd be either MAKE_SEND or MOVE_SEND <youpi>again, look at what is known to work, e.g. libmachdev/net.c <damo22>when i put SEND_ONCE it doesnt have the spurious messages <youpi>don't set *devp like in the kernel, the mig rules are not the same <youpi>perhaps, but most probably for a bad reason <youpi>SEND_ONCe really doesn't make sens here <youpi>you are giving a way to do only *one* thing on the device <damo22>device_types.h says the polything is a SEND_ONCE <youpi>I don't see the word "once" in that file <damo22>type reply_port_t = polymorphic|MACH_MSG_TYPE_PORT_SEND_ONCE <youpi>why do you look at the reply_port? <youpi>device_open returns a normal port, not a reply port <youpi>make suire you resad the proper paremeters <youpi>the reply is indeed to a reply port <youpi>but what is given to it is a normal port (the last parameter) ***Emulatorman_ is now known as Emulatorman
<pep7>to whoever is developing/using GNU/Hurd, I fucking love you <3