[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Two patches for AbstractMIControl
|
You should submit patches for the master branch.
This should help:
http://wiki.eclipse.org/Getting_started_with_CDT_development
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jason Litton
> Sent: Tuesday, March 13, 2012 12:10 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Two patches for AbstractMIControl
>
> That's no problem, Marc. I'm planning on forming the patches
> today. Like I said, though, I've got 8.01. Can you point me
> at the source for 8.02 head, so I can patch the most recent?
> Thanks,
> Jason
>
> ----- Original Message -----
> From: "Marc Khouzam" <marc.khouzam@xxxxxxxxxxxx>
> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Sent: Tuesday, March 13, 2012 9:53:22 AM
> Subject: Re: [cdt-dev] Two patches for AbstractMIControl
>
> Sorry Jason, I guess I jumped the gun in my first reply.
> When I saw code, I assumed it was a patch :O
> Let me go through you email in more detail and I'll reply again.
>
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jason Litton
> > Sent: Tuesday, March 13, 2012 10:30 AM
> > To: CDT General developers list.
> > Subject: [cdt-dev] Two patches for AbstractMIControl
> >
> > I've been working on CDT 8.0.1 extensions and I've found a
> > couple of bugs in AbstractMIControl that I'd like to submit
> > patches for. The first is around line 919 in the command:
> > final String errorResult =
> > rr.getResultClass();
> >
> > if (
> > errorResult.equals(MIResultRecord.ERROR) ) {
> > String status =
> > getStatusString(commandHandle.getCommand(),response);
> > String message =
> > getBackendMessage(response);
> > Exception exception = new
> > Exception(message);
> > rm.setStatus(new
> > Status(IStatus.ERROR, GdbPlugin.PLUGIN_ID, REQUEST_FAILED,
> > status, exception));
> > }
> >
> >
> > if (commandHandle.getRequestMonitor()
> != null) {
> >
> > commandHandle.getRequestMonitor().done();
> > }
> >
> > processCommandDone(commandHandle,
> finalResult);
> >
> > If a GDB command throws an error message on the GDB traces
> > console, the request monitor will have its status set to
> > error, but the .done() method ends up throwing an exception
> > and the command handle never reaches the processCommandDone.
> > It appears the intention here was to process all commands as
> > done, whether they're errors or not. This has an effect on
> > the whole queueCommand sequence since some of the commands in
> > the queue will never be registered as done.
> >
> > Second, I've found that it's possible to overrun the queue. I
> > instrumented the calls for queueCommand and
> > processNextQueuedCommand. Then I was doing some operations
> > that were flooding the queue (1024 events). In queueCommand,
> > fCommandQueue.add(handle) would add the correct handle, but
> > in processNextQueuedCommand would sometimes pull two of one
> > handle and then skip the next handle. For example,
> > queueCommand would queue handles A, B, C, D, E, etc, but
> > processNextQueuedCommand would remove handles A, B, C, C, E.
> > Therefore, the command associated with D would never be
> > marked as completed. Higher up, I was using a countdown
> > latch, and it would get stuck.
> >
> > I have pretty simple patches for both of these bugs, but I've
> > never submitted patches before, so I need a little help with
> > that part. I've searched bugzilla and haven't found bugs for
> > these. I'm willing to file them, but I'd like to make sure
> > that I'm not replicating bugs that already exist. Second, I'm
> > trying to come up with reproduction for the bugs. I've found
> > them through our extensions. The first bug, I'm trying to
> > figure out something that will always cause a GDB error. For
> > the second, I was flooding with monitor commands. I can
> > probably knock up a method to run 1024 memory reads, but I
> > assume this would have to be an external class that you could
> > run. Does this need to have a GUI interface? Should it be an
> > independent plugin? I'd just like to make sure that I do this
> > right. Any tips would be greatly appreciated.
> > Thanks,
> > Jason Litton
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>