Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote: > Hi, > > In the patch attached to this e-mail I included Matthew Fleming's patch > aswell. > > 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles > the words of the callout and USB API's terminology for doing the same. > > 2) I turns out I need to have code in subr_taskqueue.c to be able to make the > operations atomic. > > 3) I did not update the manpage in this patch. Will do that before a commit. > > 4) My patch implements separate state keeping in "struct task_pair", which > avoids having to change any KPI's for now, like suggested by John Baldwin I > think. > > 5) In my implementation I hard-coded the priority argument to zero, so that > enqueuing is fast. > > Comments are welcome! The patch looks almost you moved usb_process.c code into taskqueue(9) that I means it still follows that a entry which enqueued at last should be executed at last. It seems that at least it's not a general for taskqueue(9). In my humble opinion it looks a trick. I think it'd better to find a general solution to solve it though I used sx(9) lock in my patches. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: siftr LOR: PFil hook read/write mutex vs. tcp
On 6 November 2010 20:27, Bruce Cran wrote: > 1st 0x80990308 PFil read/write mutex (PFil hook read/write > mutex @ /usr/src/head/sys/net/pfil.c:77 > 2nd 0x80991528 tcp (tcp) > @ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702 > KDB: stack backtrace: > db_trace_self_wrapper() > kdb_backtrace() > _witness_debugger() > witness_checkorder() > _rw_rlock() > siftr_chkpkt() > pfil_run_hooks() > ip_input() > netisr_dispatch_src() > ether_demux() > ether_input() > msk_handle_events() > msk_intr() > intr_event_execute_handlers() > ithread_loop() > fork_exit() > fork_trampoline() > --- trap 0, rip = 0, rsp = 0xff8123559cf0, rbp = 0 --- > AFAIK, this LOR is documented in siftr(4) as harmless. -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: > Hi, > > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> I think you're misunderstanding the existing taskqueue(9) implementation. >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, >> nor can the set of running tasks. So the order of checks is >> irrelevant. > > I agree that the order of checks is not important. That is not the problem. > > Cut & paste from suggested taskqueue patch from Fleming: > > > +int >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> > +{ >> > + int rc; >> > + >> > + TQ_LOCK(queue); >> > + if (!task_is_running(queue, task)) { >> > + if ((rc = task->ta_pending) > 0) >> > + STAILQ_REMOVE(&queue->tq_queue, task, task, >> > ta_link); + task->ta_pending = 0; >> > + } else { >> > + rc = -EBUSY; > > What happens in this case if ta_pending > 0. Are you saying this is not > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? Ah! I see what you mean. I'm not quite sure what the best thing to do here is; I agree it would be nice if taskqueue_cancel(9) dequeued the task, but I believe it also needs to indicate that the task is currently running. I guess the best thing would be to return the old pending count by reference parameter, and 0 or EBUSY to also indicate if there is a task currently running. Adding jhb@ to this mail since he has good thoughts on interfacing. Thanks, matthew > >> > + } >> > + TQ_UNLOCK(queue); >> > + return (rc); >> > +} >> > >> >> As John said, the taskqueue(9) implementation cannot protect consumers >> of it from re-queueing a task; that kind of serialization needs to >> happen at a higher level. > > Agreed, but that is not what I'm pointing at. I'm pointing at what happens if > you re-queue a task and then cancel while it is actually running. Will the > task still be queued for execution after taskqueue_cancel()? > >> taskqueue(9) is not quite like callout(9); the taskqueue(9) >> implementation drops all locks before calling the task's callback >> function. So once the task is running, taskqueue(9) can do nothing >> about it until the task stops running. > > This is not the problem. > >> >> This is why Jeff's >> implementation of taskqueue_cancel(9) slept if the task was running, >> and why mine returns an error code. The only way to know for sure >> that a task is "about" to run is to ask taskqueue(9), because there's >> a window where the TQ_LOCK is dropped before the callback is entered. > > And if you re-queue and cancel in this window, shouldn't this also be handled > like in the other cases? > > Cut & paste from kern/subr_taskqueue.c: > > task->ta_pending = 0; > tb.tb_running = task; > TQ_UNLOCK(queue); > > If a concurrent thread at exactly this point in time calls taskqueue_enqueue() > on this task, then we re-add the task to the "queue->tq_queue". So far we > agree. Imagine now that for some reason a following call to taskqueue_cancel() > on this task at same point in time. Now, shouldn't taskqueue_cancel() also > remove the task from the "queue->tq_queue" in this case aswell? Because in > your implementation you only remove the task if we are not running, and that > is not true when we are at exactly this point in time. > > task->ta_func(task->ta_context, pending); > > TQ_LOCK(queue); > tb.tb_running = NULL; > wakeup(task); > > > Another issue I noticed is that the ta_pending counter should have a wrap > protector. > > --HPS > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: invalid PDPE on recend amd64
Paul B Mahol wrote: On 11/6/10, Jia-Shiun Li wrote: Hi, I got a similar panic on amd64. Looking into the source it hit KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with a printf to see what triggered the assertion and here is the output. Combined with memcontrol output 'bogus' keyword it seems buggy BIOS violated some kind of spec and caused this. Is it fatal? It looks fine on my machine without the assertion. Send uname output. The fix for this issue got commited few days ago. This is a different type of BIOS misconfiguration than your machine had. I'm attaching a possible patch for this one. Regards, Alan Index: amd64/amd64/amd64_mem.c === --- amd64/amd64/amd64_mem.c (revision 214679) +++ amd64/amd64/amd64_mem.c (working copy) @@ -583,7 +583,7 @@ amd64_mrset(struct mem_range_softc *sc, struct mem i = (sc->mr_cap & MR686_FIXMTRR) ? MTRR_N64K + MTRR_N16K + MTRR_N4K : 0; mrd = sc->mr_desc + i; for (; i < sc->mr_ndesc; i++, mrd++) { - if (mrd->mr_flags & MDF_ACTIVE) + if ((mrd->mr_flags & (MDF_ACTIVE | MDF_BOGUS)) == MDF_ACTIVE) pmap_demote_DMAP(mrd->mr_base, mrd->mr_len, FALSE); } @@ -688,7 +688,7 @@ amd64_mrinit(struct mem_range_softc *sc) i = (sc->mr_cap & MR686_FIXMTRR) ? MTRR_N64K + MTRR_N16K + MTRR_N4K : 0; mrd = sc->mr_desc + i; for (; i < sc->mr_ndesc; i++, mrd++) { - if (mrd->mr_flags & MDF_ACTIVE) + if ((mrd->mr_flags & (MDF_ACTIVE | MDF_BOGUS)) == MDF_ACTIVE) pmap_demote_DMAP(mrd->mr_base, mrd->mr_len, TRUE); } } ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: invalid PDPE on recend amd64
On 11/6/10, Jia-Shiun Li wrote: > Hi, > > I got a similar panic on amd64. Looking into the source it hit > KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with > a printf to see what triggered the assertion and here is the output. > Combined with memcontrol output 'bogus' keyword it seems buggy BIOS > violated some kind of spec and caused this. Is it fatal? It looks fine > on my machine without the assertion. Send uname output. The fix for this issue got commited few days ago. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ctrl-alt-delete in syscons pause/scrollback mode breaks system
On 11/6/10, Bruce Cran wrote: > Today I came back to my computer and realised I'd left ttyv0 in > history/scrollback mode, with scroll-lock enabled. To see what > would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to > see that it seemed to get partway through the process but it never > rebooted: the other ttys were killed and I could still break into the > debugger but otherwise the system was unresponsive. Trying to repeat > it after rebooting I ended up with a system that won't even break into > the debugger. Is this expected? Last issue, was reported my me long ago and only workaround was commited, which actually did not solved problem for me. I'm still looking forward for complete syscons rewrite. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Ctrl-alt-delete in syscons pause/scrollback mode breaks system
Today I came back to my computer and realised I'd left ttyv0 in history/scrollback mode, with scroll-lock enabled. To see what would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to see that it seemed to get partway through the process but it never rebooted: the other ttys were killed and I could still break into the debugger but otherwise the system was unresponsive. Trying to repeat it after rebooting I ended up with a system that won't even break into the debugger. Is this expected? -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: invalid PDPE on recend amd64
Hi, I got a similar panic on amd64. Looking into the source it hit KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with a printf to see what triggered the assertion and here is the output. Combined with memcontrol output 'bogus' keyword it seems buggy BIOS violated some kind of spec and caused this. Is it fatal? It looks fine on my machine without the assertion. --->8--boot message ->8 mem: base 0xfffdc000 len 0x0002 base 0xc000 len 0x4000 base 0x len 0x8000 base 0x8000 len 0x4000 base 0xbff0 len 0x0010 base 0x0001 len 0x4000 null: --->8--memcontrol output ->8 r...@jsli-nb:~ # memcontrol list 0x0/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x1/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x2/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x3/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x4/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x5/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x6/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x7/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x84000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x88000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x94000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x98000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0xa/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xac000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xca000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xce000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xda000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdc000/0x1000 BIOS write-protect fixed-base fixe
siftr LOR: PFil hook read/write mutex vs. tcp
1st 0x80990308 PFil read/write mutex (PFil hook read/write mutex @ /usr/src/head/sys/net/pfil.c:77 2nd 0x80991528 tcp (tcp) @ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702 KDB: stack backtrace: db_trace_self_wrapper() kdb_backtrace() _witness_debugger() witness_checkorder() _rw_rlock() siftr_chkpkt() pfil_run_hooks() ip_input() netisr_dispatch_src() ether_demux() ether_input() msk_handle_events() msk_intr() intr_event_execute_handlers() ithread_loop() fork_exit() fork_trampoline() --- trap 0, rip = 0, rsp = 0xff8123559cf0, rbp = 0 --- -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: man(1) no longer understands manpages like .so man3/printf.3
On Fri, Nov 5, 2010 at 8:57 AM, Anonymous wrote: > A few examples from ports tree > > devel/automake111: automake-1.11(1) > devel/gettext: dcgettext(3), dcngettext(3), dgettext(3), dngettext(3) > devel/nasm: rdf2com(1), rdf2ihx(1), rdf2ith(1), rdf2srec(1) > textproc/gnugrep: egrep(1), fgrep(1) > www/neon29: ne_get_{request,session}_flag(3), ne_set_connect_timeout(3) > x11/libX11: BlackPixel(3), XArc(3), etc > x11/libXext: XShmAttach(3), XmbufDisplayBuffers(3), etc > [+ more x11 libs] Thanks for the report. I'll look into adding the feature. Gordon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording
El día Friday, November 05, 2010 a las 01:13:15AM +0200, Alexander Motin escribió: > > # mixer -f /dev/mixer1 > > Mixer rec is currently set to 100:100 > > Mixer monitor is currently set to 100:100 > > Recording source: monitor > > That's strange. I would expect it working. > > > Would you be so kind and give me the lines for reconfigure CODEC using > > hints? I'm really lost in this. > > OK, try this: > hint.hdac.0.cad0.nid18.config="as=2 seq=1" I've tried this and a lot of other hint.hdac for which I now have some kind of understanding... all with no luck; it is only recording noice (not silense, but noise). I think there is something wrong either with the hardware or something in the driver, because searching in Google for "acer aspire one mic" I found a lot of complaints about the internal mic not working, for example in Ubuntu it needs some special tweaking: http://ubuntuforums.org/showthread.php?t=952568 https://help.ubuntu.com/community/AspireOneAOD250 (the last one speaks about some alsa driver) What do you think about? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
Hi, On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > > I think you're misunderstanding the existing taskqueue(9) implementation. > > As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > nor can the set of running tasks. So the order of checks is > irrelevant. I agree that the order of checks is not important. That is not the problem. Cut & paste from suggested taskqueue patch from Fleming: > +int > > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > > +{ > > + int rc; > > + > > + TQ_LOCK(queue); > > + if (!task_is_running(queue, task)) { > > + if ((rc = task->ta_pending) > 0) > > + STAILQ_REMOVE(&queue->tq_queue, task, task, > > ta_link); + task->ta_pending = 0; > > + } else { > > + rc = -EBUSY; What happens in this case if ta_pending > 0. Are you saying this is not possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > > + } > > + TQ_UNLOCK(queue); > > + return (rc); > > +} > > > As John said, the taskqueue(9) implementation cannot protect consumers > of it from re-queueing a task; that kind of serialization needs to > happen at a higher level. Agreed, but that is not what I'm pointing at. I'm pointing at what happens if you re-queue a task and then cancel while it is actually running. Will the task still be queued for execution after taskqueue_cancel()? > taskqueue(9) is not quite like callout(9); the taskqueue(9) > implementation drops all locks before calling the task's callback > function. So once the task is running, taskqueue(9) can do nothing > about it until the task stops running. This is not the problem. > > This is why Jeff's > implementation of taskqueue_cancel(9) slept if the task was running, > and why mine returns an error code. The only way to know for sure > that a task is "about" to run is to ask taskqueue(9), because there's > a window where the TQ_LOCK is dropped before the callback is entered. And if you re-queue and cancel in this window, shouldn't this also be handled like in the other cases? Cut & paste from kern/subr_taskqueue.c: task->ta_pending = 0; tb.tb_running = task; TQ_UNLOCK(queue); If a concurrent thread at exactly this point in time calls taskqueue_enqueue() on this task, then we re-add the task to the "queue->tq_queue". So far we agree. Imagine now that for some reason a following call to taskqueue_cancel() on this task at same point in time. Now, shouldn't taskqueue_cancel() also remove the task from the "queue->tq_queue" in this case aswell? Because in your implementation you only remove the task if we are not running, and that is not true when we are at exactly this point in time. task->ta_func(task->ta_context, pending); TQ_LOCK(queue); tb.tb_running = NULL; wakeup(task); Another issue I noticed is that the ta_pending counter should have a wrap protector. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Sat, Nov 6, 2010 at 1:37 AM, Hans Petter Selasky wrote: > On Friday 05 November 2010 20:06:12 John Baldwin wrote: >> On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: >> > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: >> > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky >> > >> > wrote: >> > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: >> > > >> True, but no taskqueue(9) code can handle that. Only the caller can >> > > >> prevent a task from becoming enqueued again. The same issue exists >> > > >> with taskqueue_drain(). >> > > > >> > > > I find that strange, because that means if I queue a task again while >> > > > it is running, then I doesn't get run? Are you really sure? >> > > >> > > If a task is currently running when enqueued, the task struct will be >> > > re-enqueued to the taskqueue. When that task comes up as the head of >> > > the queue, it will be run again. >> > >> > Right, and the taskqueue_cancel has to cancel in that state to, but it >> > doesn't because it only checks pending if !running() :-) ?? >> >> You can't close that race in taskqueue_cancel(). You have to manage that >> race yourself in your task handler. For the callout(9) API we are only >> able to close that race if you use callout_init_mtx() so that the code >> managing the callout wheel can make use of your lock to resolve the races. >> If you use callout_init() you have to explicitly manage these races in your >> callout handler. > > Hi, > > I think you are getting me wrong! In the initial "0001-Implement- > taskqueue_cancel-9-to-cancel-a-task-from-a.patch" you have the following code- > chunk: > > +int > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > +{ > + int rc; > + > + TQ_LOCK(queue); > + if (!task_is_running(queue, task)) { > + if ((rc = task->ta_pending) > 0) > + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); > + task->ta_pending = 0; > + } else > + rc = -EBUSY; > + TQ_UNLOCK(queue); > + return (rc); > +} > > This code should be written like this, having the if (!task_is_running()) > after checking the ta_pending variable. > > +int > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > +{ > + int rc; > + > + TQ_LOCK(queue); > + if ((rc = task->ta_pending) > 0) { > + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); > + task->ta_pending = 0; > + } > + if (!task_is_running(queue, task)) > + rc = -EBUSY; > + TQ_UNLOCK(queue); > + return (rc); > +} > > Or completely skip the !task_is_running() check. Else you are opening up a > race in this function! Do I need to explain that more? Isn't it obvious? I think you're misunderstanding the existing taskqueue(9) implementation. As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, nor can the set of running tasks. So the order of checks is irrelevant. As John said, the taskqueue(9) implementation cannot protect consumers of it from re-queueing a task; that kind of serialization needs to happen at a higher level. taskqueue(9) is not quite like callout(9); the taskqueue(9) implementation drops all locks before calling the task's callback function. So once the task is running, taskqueue(9) can do nothing about it until the task stops running. This is why Jeff's implementation of taskqueue_cancel(9) slept if the task was running, and why mine returns an error code. The only way to know for sure that a task is "about" to run is to ask taskqueue(9), because there's a window where the TQ_LOCK is dropped before the callback is entered. Thanks, matthew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:44 AM, Barbara wrote: > >>On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote: >>> >>> On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote: > > I had a problem running the IcedTea java plugin on CURRENT i386, while it > works on 8_STABLE. > But maybe it's not a problem related to the port. > Just to be clear, I'm not looking for a solution about the port here, I'm >>> just > wondering why the same c++ code is working on 8_STABLE and it's > segfaulting >>> on > CURRENT, considering also that AFAIK the gcc version in both the base >>> systems > is the same. > > In the part of the code causing the crash, a std::map is read with an >>> iterator > in a for loop, and if a condition is met, an entry is erased. > The following is the bt I'm getting: > #0 0x29e36247 in kill () from /lib/libc.so.7 > #1 0x29e361a6 in raise () from /lib/libc.so.7 > #2 0x282424f6 in XRE_LockProfileDirectory () from > /usr/local/lib/firefox3/libxul.so > #3 > #4 0x29c8f1b2 in std::_Rb_tree_increment () from > /usr/lib/libstdc++.so.6 #5 0x2ef92402 in > IcedTeaPluginUtilities::invalidateInstance () from > /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so > ... > > I wrote a "patch" for the IcedTea plugin, replacing the for loop with a >>> while > and increasing the iterator before erasing from the map, and it seems >>> working. > Then I wrote a simple program that do something similar to IcedTea, so >>> there > is no need to build the whole java/openjdk6 port to do some testing. > Running it on 8_STABLE it works, on CURRENT it crashes. > You can find more details in this discussion on the freebsd-java ml: > http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html > > You can find the patch and the sample code in the discussion above, > anyway >>> I'm > reporting them here too: > icedtea patch: > http://pastebin.com/b2KKFNSG > test case: > http://pastebin.com/Amk4UJ0g You appear to invalidate the iterator inside the loop and then increment it. Do the following: -- cut here -- for (iter = cars.begin(); iter != cars.end(); ) { if ((*iter).second == modelName) cars.erase(iter++); else ++iter; } -- and here -- In this example, you first increment the iterator and then erase its previous value. >>> >>> So there is a bug in my source code! Well, I'm not surprised. >>> >>> I'm trying to report the code in icedtea here, extracting it from the patch > so >>> I hope it's accurate enough: >>> >>> std::map::iterator iterator; >>> for (iterator = instance_map->begin(); iterator != instance_map->end(); >>> iterator++) >>> { >>> if ((*iterator).second == instance) >>> { >>> instance_map->erase((*iterator).first); >>> } >>> } >>> >>> So, do you think, like Ed Schouten said, that there is a bug in the source >>> code but it's just exposed on CURRENT? >>> Is that code bad too? >>> >>> Thanks >>> Barbara >>> >>> >> >>Yes, I believe CURRENT's malloc zeroes out the memory upon deletion, >>whereas STABLE doesn't. So in STABLE you get an old copy of the >>invalidated iterator, hence it works. >> > > Very nice explanation. > > Thanks > > I hope I'm right, I don't have CURRENT installed, it's just an assumption. However, the C++ code is most definitely buggy. -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
R: Re: libstc++ (?) problem on CURRENT?
>On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote: >> >> >>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote: I had a problem running the IcedTea java plugin on CURRENT i386, while it works on 8_STABLE. But maybe it's not a problem related to the port. Just to be clear, I'm not looking for a solution about the port here, I'm >> just wondering why the same c++ code is working on 8_STABLE and it's segfaulting >> on CURRENT, considering also that AFAIK the gcc version in both the base >> systems is the same. In the part of the code causing the crash, a std::map is read with an >> iterator in a for loop, and if a condition is met, an entry is erased. The following is the bt I'm getting: #0 0x29e36247 in kill () from /lib/libc.so.7 #1 0x29e361a6 in raise () from /lib/libc.so.7 #2 0x282424f6 in XRE_LockProfileDirectory () from /usr/local/lib/firefox3/libxul.so #3 #4 0x29c8f1b2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #5 0x2ef92402 in IcedTeaPluginUtilities::invalidateInstance () from /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so ... I wrote a "patch" for the IcedTea plugin, replacing the for loop with a >> while and increasing the iterator before erasing from the map, and it seems >> working. Then I wrote a simple program that do something similar to IcedTea, so >> there is no need to build the whole java/openjdk6 port to do some testing. Running it on 8_STABLE it works, on CURRENT it crashes. You can find more details in this discussion on the freebsd-java ml: http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html You can find the patch and the sample code in the discussion above, anyway >> I'm reporting them here too: icedtea patch: http://pastebin.com/b2KKFNSG test case: http://pastebin.com/Amk4UJ0g >>> >>>You appear to invalidate the iterator inside the loop and then >>>increment it. Do the following: >>> >>>-- cut here -- >>>for (iter = cars.begin(); iter != cars.end(); ) { >>> if ((*iter).second == modelName) >>> cars.erase(iter++); >>> else >>> ++iter; >>>} >>>-- and here -- >>> >>>In this example, you first increment the iterator and then erase its >>>previous value. >>> >> >> So there is a bug in my source code! Well, I'm not surprised. >> >> I'm trying to report the code in icedtea here, extracting it from the patch so >> I hope it's accurate enough: >> >> std::map::iterator iterator; >> for (iterator = instance_map->begin(); iterator != instance_map->end(); >> iterator++) >> { >> if ((*iterator).second == instance) >> { >> instance_map->erase((*iterator).first); >> } >> } >> >> So, do you think, like Ed Schouten said, that there is a bug in the source >> code but it's just exposed on CURRENT? >> Is that code bad too? >> >> Thanks >> Barbara >> >> > >Yes, I believe CURRENT's malloc zeroes out the memory upon deletion, >whereas STABLE doesn't. So in STABLE you get an old copy of the >invalidated iterator, hence it works. > Very nice explanation. Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote: > > I had a problem running the IcedTea java plugin on CURRENT i386, while it > works on 8_STABLE. > But maybe it's not a problem related to the port. > Just to be clear, I'm not looking for a solution about the port here, I'm just > wondering why the same c++ code is working on 8_STABLE and it's segfaulting on > CURRENT, considering also that AFAIK the gcc version in both the base systems > is the same. > > In the part of the code causing the crash, a std::map is read with an iterator > in a for loop, and if a condition is met, an entry is erased. > The following is the bt I'm getting: > #0 0x29e36247 in kill () from /lib/libc.so.7 > #1 0x29e361a6 in raise () from /lib/libc.so.7 > #2 0x282424f6 in XRE_LockProfileDirectory () from > /usr/local/lib/firefox3/libxul.so > #3 > #4 0x29c8f1b2 in std::_Rb_tree_increment () from > /usr/lib/libstdc++.so.6 #5 0x2ef92402 in > IcedTeaPluginUtilities::invalidateInstance () from > /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so > ... > > I wrote a "patch" for the IcedTea plugin, replacing the for loop with a while > and increasing the iterator before erasing from the map, and it seems working. > Then I wrote a simple program that do something similar to IcedTea, so there > is no need to build the whole java/openjdk6 port to do some testing. > Running it on 8_STABLE it works, on CURRENT it crashes. > You can find more details in this discussion on the freebsd-java ml: > http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html > > You can find the patch and the sample code in the discussion above, anyway I'm > reporting them here too: > icedtea patch: > http://pastebin.com/b2KKFNSG > test case: > http://pastebin.com/Amk4UJ0g You appear to invalidate the iterator inside the loop and then increment it. Do the following: -- cut here -- for (iter = cars.begin(); iter != cars.end(); ) { if ((*iter).second == modelName) cars.erase(iter++); else ++iter; } -- and here -- In this example, you first increment the iterator and then erase its previous value. -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:32 AM, Vlad Galu wrote: > On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu wrote: >> On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote: >>> >>> I had a problem running the IcedTea java plugin on CURRENT i386, while it >>> works on 8_STABLE. >>> But maybe it's not a problem related to the port. >>> Just to be clear, I'm not looking for a solution about the port here, I'm >>> just >>> wondering why the same c++ code is working on 8_STABLE and it's segfaulting >>> on >>> CURRENT, considering also that AFAIK the gcc version in both the base >>> systems >>> is the same. >>> >>> In the part of the code causing the crash, a std::map is read with an >>> iterator >>> in a for loop, and if a condition is met, an entry is erased. >>> The following is the bt I'm getting: >>> #0 0x29e36247 in kill () from /lib/libc.so.7 >>> #1 0x29e361a6 in raise () from /lib/libc.so.7 >>> #2 0x282424f6 in XRE_LockProfileDirectory () from >>> /usr/local/lib/firefox3/libxul.so >>> #3 >>> #4 0x29c8f1b2 in std::_Rb_tree_increment () from >>> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in >>> IcedTeaPluginUtilities::invalidateInstance () from >>> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >>> ... >>> >>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a >>> while >>> and increasing the iterator before erasing from the map, and it seems >>> working. >>> Then I wrote a simple program that do something similar to IcedTea, so there >>> is no need to build the whole java/openjdk6 port to do some testing. >>> Running it on 8_STABLE it works, on CURRENT it crashes. >>> You can find more details in this discussion on the freebsd-java ml: >>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html >>> >>> You can find the patch and the sample code in the discussion above, anyway >>> I'm >>> reporting them here too: >>> icedtea patch: >>> http://pastebin.com/b2KKFNSG >>> test case: >>> http://pastebin.com/Amk4UJ0g >> >> You appear to invalidate the iterator inside the loop and then >> increment it. Do the following: >> >> -- cut here -- >> for (iter = cars.begin(); iter != cars.end(); ) { >> if ((*iter).second == modelName) >> cars.erase(iter++); >> else >> ++iter; >> } >> -- and here -- >> >> In this example, you first increment the iterator and then erase its >> previous value. > > Or, better yet: cars.erase("punto"); I see no reason in iterating > through the whole map unless you want to relate the deletion to the > matched type, in which case you should use the previous example. > Sorry, I meant mapped type. -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote: > > >>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote: >>> >>> I had a problem running the IcedTea java plugin on CURRENT i386, while it >>> works on 8_STABLE. >>> But maybe it's not a problem related to the port. >>> Just to be clear, I'm not looking for a solution about the port here, I'm > just >>> wondering why the same c++ code is working on 8_STABLE and it's segfaulting > on >>> CURRENT, considering also that AFAIK the gcc version in both the base > systems >>> is the same. >>> >>> In the part of the code causing the crash, a std::map is read with an > iterator >>> in a for loop, and if a condition is met, an entry is erased. >>> The following is the bt I'm getting: >>> #0 0x29e36247 in kill () from /lib/libc.so.7 >>> #1 0x29e361a6 in raise () from /lib/libc.so.7 >>> #2 0x282424f6 in XRE_LockProfileDirectory () from >>> /usr/local/lib/firefox3/libxul.so >>> #3 >>> #4 0x29c8f1b2 in std::_Rb_tree_increment () from >>> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in >>> IcedTeaPluginUtilities::invalidateInstance () from >>> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >>> ... >>> >>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a > while >>> and increasing the iterator before erasing from the map, and it seems > working. >>> Then I wrote a simple program that do something similar to IcedTea, so > there >>> is no need to build the whole java/openjdk6 port to do some testing. >>> Running it on 8_STABLE it works, on CURRENT it crashes. >>> You can find more details in this discussion on the freebsd-java ml: >>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html >>> >>> You can find the patch and the sample code in the discussion above, anyway > I'm >>> reporting them here too: >>> icedtea patch: >>> http://pastebin.com/b2KKFNSG >>> test case: >>> http://pastebin.com/Amk4UJ0g >> >>You appear to invalidate the iterator inside the loop and then >>increment it. Do the following: >> >>-- cut here -- >>for (iter = cars.begin(); iter != cars.end(); ) { >> if ((*iter).second == modelName) >> cars.erase(iter++); >> else >> ++iter; >>} >>-- and here -- >> >>In this example, you first increment the iterator and then erase its >>previous value. >> > > So there is a bug in my source code! Well, I'm not surprised. > > I'm trying to report the code in icedtea here, extracting it from the patch so > I hope it's accurate enough: > > std::map::iterator iterator; > for (iterator = instance_map->begin(); iterator != instance_map->end(); > iterator++) > { > if ((*iterator).second == instance) > { > instance_map->erase((*iterator).first); > } > } > > So, do you think, like Ed Schouten said, that there is a bug in the source > code but it's just exposed on CURRENT? > Is that code bad too? > > Thanks > Barbara > > Yes, I believe CURRENT's malloc zeroes out the memory upon deletion, whereas STABLE doesn't. So in STABLE you get an old copy of the invalidated iterator, hence it works. -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu wrote: > On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote: >> >> I had a problem running the IcedTea java plugin on CURRENT i386, while it >> works on 8_STABLE. >> But maybe it's not a problem related to the port. >> Just to be clear, I'm not looking for a solution about the port here, I'm >> just >> wondering why the same c++ code is working on 8_STABLE and it's segfaulting >> on >> CURRENT, considering also that AFAIK the gcc version in both the base systems >> is the same. >> >> In the part of the code causing the crash, a std::map is read with an >> iterator >> in a for loop, and if a condition is met, an entry is erased. >> The following is the bt I'm getting: >> #0 0x29e36247 in kill () from /lib/libc.so.7 >> #1 0x29e361a6 in raise () from /lib/libc.so.7 >> #2 0x282424f6 in XRE_LockProfileDirectory () from >> /usr/local/lib/firefox3/libxul.so >> #3 >> #4 0x29c8f1b2 in std::_Rb_tree_increment () from >> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in >> IcedTeaPluginUtilities::invalidateInstance () from >> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >> ... >> >> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a while >> and increasing the iterator before erasing from the map, and it seems >> working. >> Then I wrote a simple program that do something similar to IcedTea, so there >> is no need to build the whole java/openjdk6 port to do some testing. >> Running it on 8_STABLE it works, on CURRENT it crashes. >> You can find more details in this discussion on the freebsd-java ml: >> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html >> >> You can find the patch and the sample code in the discussion above, anyway >> I'm >> reporting them here too: >> icedtea patch: >> http://pastebin.com/b2KKFNSG >> test case: >> http://pastebin.com/Amk4UJ0g > > You appear to invalidate the iterator inside the loop and then > increment it. Do the following: > > -- cut here -- > for (iter = cars.begin(); iter != cars.end(); ) { > if ((*iter).second == modelName) > cars.erase(iter++); > else > ++iter; > } > -- and here -- > > In this example, you first increment the iterator and then erase its > previous value. Or, better yet: cars.erase("punto"); I see no reason in iterating through the whole map unless you want to relate the deletion to the matched type, in which case you should use the previous example. -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
libstc++ (?) problem on CURRENT?
>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote: >> >> I had a problem running the IcedTea java plugin on CURRENT i386, while it >> works on 8_STABLE. >> But maybe it's not a problem related to the port. >> Just to be clear, I'm not looking for a solution about the port here, I'm just >> wondering why the same c++ code is working on 8_STABLE and it's segfaulting on >> CURRENT, considering also that AFAIK the gcc version in both the base systems >> is the same. >> >> In the part of the code causing the crash, a std::map is read with an iterator >> in a for loop, and if a condition is met, an entry is erased. >> The following is the bt I'm getting: >> #0 0x29e36247 in kill () from /lib/libc.so.7 >> #1 0x29e361a6 in raise () from /lib/libc.so.7 >> #2 0x282424f6 in XRE_LockProfileDirectory () from >> /usr/local/lib/firefox3/libxul.so >> #3 >> #4 0x29c8f1b2 in std::_Rb_tree_increment () from >> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in >> IcedTeaPluginUtilities::invalidateInstance () from >> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >> ... >> >> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a while >> and increasing the iterator before erasing from the map, and it seems working. >> Then I wrote a simple program that do something similar to IcedTea, so there >> is no need to build the whole java/openjdk6 port to do some testing. >> Running it on 8_STABLE it works, on CURRENT it crashes. >> You can find more details in this discussion on the freebsd-java ml: >> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html >> >> You can find the patch and the sample code in the discussion above, anyway I'm >> reporting them here too: >> icedtea patch: >> http://pastebin.com/b2KKFNSG >> test case: >> http://pastebin.com/Amk4UJ0g > >You appear to invalidate the iterator inside the loop and then >increment it. Do the following: > >-- cut here -- >for (iter = cars.begin(); iter != cars.end(); ) { > if ((*iter).second == modelName) > cars.erase(iter++); > else > ++iter; >} >-- and here -- > >In this example, you first increment the iterator and then erase its >previous value. > So there is a bug in my source code! Well, I'm not surprised. I'm trying to report the code in icedtea here, extracting it from the patch so I hope it's accurate enough: std::map::iterator iterator; for (iterator = instance_map->begin(); iterator != instance_map->end(); iterator++) { if ((*iterator).second == instance) { instance_map->erase((*iterator).first); } } So, do you think, like Ed Schouten said, that there is a bug in the source code but it's just exposed on CURRENT? Is that code bad too? Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
R: Re: libstc++ (?) problem on CURRENT?
>* Barbara , 20101106 10:57: >> Just to be clear, I'm not looking for a solution about the port here, >> I'm just wondering why the same c++ code is working on 8_STABLE and >> it's segfaulting on CURRENT, considering also that AFAIK the gcc >> version in both the base systems is the same. > >I am a real STL newbie, so I could be wrong. Maybe it's not allowed to >remove an element in the map you're currently iterating. Therefore >you're accessing memory which has been deallocated. > I'm sure you're not worse than me! :) Anyway that's what I was thinking when I wrote the patch. >This may crash on HEAD and not on 8-STABLE for various reasons. For >example, malloc() in HEAD has all sorts of debugging options enabled, >while 8-STABLE does not. > So you think that the problem is really in the original source code, but exposed only on CURRENT. That could be an option. Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libstc++ (?) problem on CURRENT?
* Barbara , 20101106 10:57: > Just to be clear, I'm not looking for a solution about the port here, > I'm just wondering why the same c++ code is working on 8_STABLE and > it's segfaulting on CURRENT, considering also that AFAIK the gcc > version in both the base systems is the same. I am a real STL newbie, so I could be wrong. Maybe it's not allowed to remove an element in the map you're currently iterating. Therefore you're accessing memory which has been deallocated. This may crash on HEAD and not on 8-STABLE for various reasons. For example, malloc() in HEAD has all sorts of debugging options enabled, while 8-STABLE does not. Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpVzkBGkeJh8.pgp Description: PGP signature
libstc++ (?) problem on CURRENT?
I had a problem running the IcedTea java plugin on CURRENT i386, while it works on 8_STABLE. But maybe it's not a problem related to the port. Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. In the part of the code causing the crash, a std::map is read with an iterator in a for loop, and if a condition is met, an entry is erased. The following is the bt I'm getting: #0 0x29e36247 in kill () from /lib/libc.so.7 #1 0x29e361a6 in raise () from /lib/libc.so.7 #2 0x282424f6 in XRE_LockProfileDirectory () from /usr/local/lib/firefox3/libxul.so #3 #4 0x29c8f1b2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #5 0x2ef92402 in IcedTeaPluginUtilities::invalidateInstance () from /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so ... I wrote a "patch" for the IcedTea plugin, replacing the for loop with a while and increasing the iterator before erasing from the map, and it seems working. Then I wrote a simple program that do something similar to IcedTea, so there is no need to build the whole java/openjdk6 port to do some testing. Running it on 8_STABLE it works, on CURRENT it crashes. You can find more details in this discussion on the freebsd-java ml: http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html You can find the patch and the sample code in the discussion above, anyway I'm reporting them here too: icedtea patch: http://pastebin.com/b2KKFNSG test case: http://pastebin.com/Amk4UJ0g I hope that the crash is not caused by a bad environment, can anyone else test it? Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 20:06:12 John Baldwin wrote: > On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: > > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky > > > > wrote: > > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > > > >> True, but no taskqueue(9) code can handle that. Only the caller can > > > >> prevent a task from becoming enqueued again. The same issue exists > > > >> with taskqueue_drain(). > > > > > > > > I find that strange, because that means if I queue a task again while > > > > it is running, then I doesn't get run? Are you really sure? > > > > > > If a task is currently running when enqueued, the task struct will be > > > re-enqueued to the taskqueue. When that task comes up as the head of > > > the queue, it will be run again. > > > > Right, and the taskqueue_cancel has to cancel in that state to, but it > > doesn't because it only checks pending if !running() :-) ?? > > You can't close that race in taskqueue_cancel(). You have to manage that > race yourself in your task handler. For the callout(9) API we are only > able to close that race if you use callout_init_mtx() so that the code > managing the callout wheel can make use of your lock to resolve the races. > If you use callout_init() you have to explicitly manage these races in your > callout handler. Hi, I think you are getting me wrong! In the initial "0001-Implement- taskqueue_cancel-9-to-cancel-a-task-from-a.patch" you have the following code- chunk: +int +taskqueue_cancel(struct taskqueue *queue, struct task *task) +{ + int rc; + + TQ_LOCK(queue); + if (!task_is_running(queue, task)) { + if ((rc = task->ta_pending) > 0) + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } else + rc = -EBUSY; + TQ_UNLOCK(queue); + return (rc); +} This code should be written like this, having the if (!task_is_running()) after checking the ta_pending variable. +int +taskqueue_cancel(struct taskqueue *queue, struct task *task) +{ + int rc; + + TQ_LOCK(queue); + if ((rc = task->ta_pending) > 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (!task_is_running(queue, task)) + rc = -EBUSY; + TQ_UNLOCK(queue); + return (rc); +} Or completely skip the !task_is_running() check. Else you are opening up a race in this function! Do I need to explain that more? Isn't it obvious? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"