modbus/rtu segfault (was: AutomationX and help needed.)

J

Thread Starter

Jiri Baum

Philip Costigan:
> I have not had much time to look at modbus.rtu and I know there is a
> strange bug causing a seg fault. I'm about to head off on sunday for a
> few weeks overseas.

When the baud rate is not specified, io/modbus/rtu/tags.c:100 sets the baud variable to NULL. Then tags.c:113 tries to strncpy(3) it somewhere.

What should the default baud rate be?


BTW, is there any reason to pass the baud rate around as a string? Probably better to get it as an integer from the config and pass around that...

Jiri
--
Jiri Baum <[email protected]>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Philip Costigan

On Thu, 23 Nov 2000, Jiri Baum wrote:
> Philip Costigan:
> > I have not had much time to look at modbus.rtu and I know there is a
> > strange bug causing a seg fault. I'm about to head off on sunday for a
> > few weeks overseas.
>
> When the baud rate is not specified, io/modbus/rtu/tags.c:100 sets the baud
> variable to NULL. Then tags.c:113 tries to strncpy(3) it somewhere.
>
> What should the default baud rate be?

9600

> BTW, is there any reason to pass the baud rate around as a string? Probably
> better to get it as an integer from the config and pass around that...

I think I started to do that on my private copy but never got around to publishing. You are right though, an integer would be nicer.

Regards

Philip Costigan

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > When the baud rate is not specified, io/modbus/rtu/tags.c:100 sets the baud
> > variable to NULL. Then tags.c:113 tries to strncpy(3) it somewhere.

> > What should the default baud rate be?

Philip Costigan:
> 9600

OK, I guess the parity is going to have the same problem; should it default to "none" ?

BTW, I think that function is a big memory-leak. I'm not sure whether I should go through and free() everything, or change the io_file struct to
use char* instead of char[].

Jiri
--
Jiri Baum <[email protected]>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Philip Costigan

On Fri, 24 Nov 2000, Jiri Baum wrote:

> Jiri Baum:
> > > When the baud rate is not specified, io/modbus/rtu/tags.c:100 sets the baud
> > > variable to NULL. Then tags.c:113 tries to strncpy(3) it somewhere.
>
> > > What should the default baud rate be?
>
> Philip Costigan:
> > 9600
>
> OK, I guess the parity is going to have the same problem; should it default
> to "none" ?

I think Odd is the default.

> BTW, I think that function is a big memory-leak. I'm not sure whether I
> should go through and free() everything, or change the io_file struct to
> use char* instead of char[].

This stuff is a little beyond me just at the moment but if you think that it would be better as char* then go with it and down the track it will get tested by us or a beta tester.

--

Regards

Philip Costigan


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > OK, I guess the parity is going to have the same problem; should it
> > default to "none" ?

Philip Costigan:
> I think Odd is the default.

OK, changed.

> > BTW, I think that function is a big memory-leak. I'm not sure whether I
> > should go through and free() everything, or change the io_file struct
> > to use char* instead of char[].

> This stuff is a little beyond me just at the moment but if you think that
> it would be better as char* then go with it and down the track it will
> get tested by us or a beta tester.

OK. char* has the advantage that no length limits need apply, and the disadvantage that you have to malloc(3) and free(3) always. Some of the fields be better if they weren't strings, anyway.

I can go through and change them, but I have the disadvantage that I don't have the hardware in question, so I can't really test it.

Jiri
--
Jiri Baum <[email protected]>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > BTW, is there any reason to pass the baud rate around as a string?
> > Probably better to get it as an integer from the config and pass around
> > that...

Philip Costigan:
> I think I started to do that on my private copy but never got around to
> publishing. You are right though, an integer would be nicer.

OK, it's an integer now, and I've also eliminated the io_types field (the info was already in the enumerated `type' field).

That leaves parity, and maybe some others, plus the memory leaks from the remaining strings. But not tonight...


BTW, what is the 10 on tags.c:182 ?
pointer->retry_port_time = time( NULL ) - 10;


Jiri
--
Jiri Baum <[email protected]>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Philip Costigan

> BTW, what is the 10 on tags.c:182 ?
> pointer->retry_port_time = time( NULL ) - 10;
>

It's a delay before retrying comms.
When I setup a comms retry in modbus_tcp without a delay between each retry the whole linux box crashed to a screaming halt. I thought that I should just keep the same idea for all protocols.

I got back from OS on Tuesday.
Wading through mail now.

--

Regards

Philip Costigan


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > BTW, what is the 10 on tags.c:182 ?
> > pointer->retry_port_time = time( NULL ) - 10;

Philip Costigan:
> It's a delay before retrying comms.

That should be a symbolic constant, if not configurable. At the very least put a comment on it.

const int comms_retry_delay = 10;


Jiri
--
Jiri Baum <[email protected]>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P
We had an internal meeting recently and felt it would be an excellent idea to write a “Class” or interfaces to support the MAT/LPLC project.

This means that users of the MAT/LPLC tools will have the option to connect directly to automationX for client distribution/connectivity with automationX’s networking. The ability to add a significant level of Soft Regulatory or Logic processing, full HMI, alarming, trending, journals, and hot redundancy.

For automationX users, the MAT/LPLC opens up additional connectivity and development tools. automationX servers are a convenient way to assemble individual MAT/LPLC applications for distribution of data to enterprise systems, etc.

The integration project is now with our Engineering Group and they have scheduled to begin reviewing the MAT project soon.

Regards,

Paul Jager
CEO
www.mnrcan.com <http://www.mnrcan.com/>

For the MAT/LPLC project see…
http://mat.sourceforge.net/

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top