[Ovmsdev] sprintf / crashes

Mark Webb-Johnson mark at webb-johnson.net
Thu Dec 20 22:38:52 HKT 2012


If you go to project settings, C18 / MPLINK, you can set a map file for the linker. Looking at what has been generated for a V2 experimental build, I get:

...
                 __AARGB4   0x000025       data     extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
                 __AARGB3   0x000026       data     extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
                 __AARGB2   0x000027       data     extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
                 __AARGB1   0x000028       data     extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
                 __AARGB0   0x000029       data     extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
                   __AEXP   0x00002a       data     extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
                 __BARGB3   0x00002b       data     extern C:\MCC18\v3_39\src\traditional\math\barg.asm
                 __BARGB2   0x00002c       data     extern C:\MCC18\v3_39\src\traditional\math\barg.asm
                 __BARGB1   0x00002d       data     extern C:\MCC18\v3_39\src\traditional\math\barg.asm
                 __BARGB0   0x00002e       data     extern C:\MCC18\v3_39\src\traditional\math\barg.asm
                   __BEXP   0x00002f       data     extern C:\MCC18\v3_39\src\traditional\math\barg.asm
                 __TEMPB3   0x000030       data     extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
                 __TEMPB2   0x000031       data     extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
                 __TEMPB1   0x000032       data     extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
                 __TEMPB0   0x000033       data     extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
                   __TEMP   0x000033       data     extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
            DelayCounter1   0x000034       data     extern C:\MCC18\v3_39\src\traditional\delays\delayd1.asm
            ovms_firmware   0x000060       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
          car_linevoltage   0x000063       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
        car_chargecurrent   0x000065       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
          car_chargelimit   0x000066       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
       car_chargeduration   0x000067       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
          car_chargestate   0x000069       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
       car_chargesubstate   0x00006a       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
           car_chargemode   0x00006b       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
            car_charge_b4   0x00006c       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
            car_chargekwh   0x00006d       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
               car_doors1   0x00006e       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
               car_doors2   0x00006f       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
               car_doors3   0x000070       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
               car_doors4   0x000071       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
            car_lockstate   0x000072       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
                car_speed   0x000073       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
                  car_SOC   0x000074       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
           car_idealrange   0x000075       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
             car_estrange   0x000077       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
                 car_time   0x000079       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
             car_parktime   0x00007d       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
         car_ambient_temp   0x000081       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
                  car_vin   0x000082       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
                 car_tpem   0x000094       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
               car_tmotor   0x000095       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
             car_tbattery   0x000096       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
               car_tpms_t   0x000097       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
               car_tpms_p   0x00009b       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
                 car_trip   0x00009f       data     extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
...

The firmware version number is right at the start, so that would explain why I'm seeing it overwritten. It is the most vulnerable.

As you can see, tpms is a little further down.

The net buffers are much later.

Data usage summary is:

                                 Section Info
                  Section       Type    Address   Location Size(Bytes)
                ---------  ---------  ---------  ---------  ---------
            .idata_ovms.o      idata   0x000060       data   0x000069
         .idata_vehicle.o      idata   0x0004d8       data   0x000028
             .idata_net.o      idata   0x0005c8       data   0x00002c
   .idata_vehicle_twizy.o      idata   0x0007e8       data   0x000014
                SEED_DATA      idata   0x0007fc       data   0x000002
             .idata_led.o      idata   0x0008c7       data   0x000005
          .idata_stokpr.o      idata   0x0008cc       data   0x000002
            .idata_diag.o      idata   0x000900       data   0x0000b9
         .idata_net_sms.o      idata   0x000a5e       data   0x00005d
         .idata_net_msg.o      idata   0x000abb       data   0x000045
       .idata_crypt_md5.o      idata   0x000b00       data   0x000040
                MATH_DATA      udata   0x000020       data   0x000014
                DELAYDAT1      udata   0x000034       data   0x000001
            .udata_ovms.o      udata   0x0000c9       data   0x00002d
           .udata_c018i.o      udata   0x0000f6       data   0x00000a
                TX_CRYPTO      udata   0x000100       data   0x000100
                RX_CRYPTO      udata   0x000200       data   0x000100
                PM_CRYPTO      udata   0x000300       data   0x000100
      .udata_crypt_hmac.o      udata   0x000400       data   0x0000d8
                NETMSG_SP      udata   0x000500       data   0x0000c8
    .udata_crypt_base64.o      udata   0x0005f4       data   0x000008
             .udata_net.o      udata   0x0005fc       data   0x000003
             .udata_led.o      udata   0x0005ff       data   0x000001
                NETBUF_SP      udata   0x000600       data   0x0000c8
         .udata_net_msg.o      udata   0x0006c8       data   0x000026
         .udata_vehicle.o      udata   0x0006ee       data   0x000012
                   NETBUF      udata   0x000700       data   0x0000c8
          .udata_params.o      udata   0x0007c8       data   0x000020
   .udata_vehicle_twizy.o      udata   0x0007fe       data   0x000002
        .udata_UARTIntC.o      udata   0x000800       data   0x0000c7
       .udata_crypt_md5.o      udata   0x0009b9       data   0x000040
         .udata_net_sms.o      udata   0x0009f9       data   0x000007
     vehicle_overlay_data      udata   0x000a00       data   0x00005e
                   .stack      udata   0x000c00       data   0x000100
              SFR_BANKED0      udata   0x000d60       data   0x00000c
              SFR_BANKED1      udata   0x000d70       data   0x00000c
              SFR_BANKED2      udata   0x000d80       data   0x00000c
              SFR_BANKED3      udata   0x000d90       data   0x000004
              SFR_BANKED4      udata   0x000dd4       data   0x000002
              SFR_BANKED5      udata   0x000dd8       data   0x000001
              SFR_BANKED6      udata   0x000de0       data   0x000008
              SFR_BANKED7      udata   0x000df0       data   0x000004
              SFR_BANKED8      udata   0x000df8       data   0x000001
              SFR_BANKED9      udata   0x000dfa       data   0x000001
             SFR_BANKED10      udata   0x000dfc       data   0x000001
             SFR_BANKED11      udata   0x000e20       data   0x000060
             SFR_BANKED12      udata   0x000f00       data   0x000060
            SFR_UNBANKED0      udata   0x000f60       data   0x000018
            SFR_UNBANKED1      udata   0x000f80       data   0x000080

Interestingly, you can see you 0x100 byte stack.

Still looking, but I reckon the problem is more likely to be sprintf() or library based than our net / net_msg / sms handlers.

Regards, Mark.

On 20 Dec, 2012, at 9:42 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:

> 
> Micheal,
> 
> My 49,51,51 is 0x31, 0x33, 0x33 - or "1", "3", "3" - similar to your 0x30 "0".
> 
> The base64 stuff in net_msg and net comms is mostly lower and uppercase letters. We see ascii encoded numbers in VINs and GPS mostly (but I am using the car's GPS and you are using the ovms module's GPS). Anywhere else we'd expect to see long strings of ascii encoded numbers?
> 
> Or, perhaps, sprintf() somewhere is going crazy and printing numbers?
> 
> Regards, Mark.
> 
> On 20 Dec, 2012, at 9:29 AM, Mark Webb-Johnson wrote:
> 
>> Michael,
>> 
>> I think our revisions overlapped. I'd just merged in all your previous changes, plus documentation and server code updates.
>> 
>> I did make some minor layout fixes (where the indentation was wrong - I think you are using 4 spaces, or perhaps tabs, where the rest of the project uses 2). I also added your pseudo-command #6 to the protocol document.
>> 
>> Can you merge in my changes, then re-push yours? I'd like to get this v2 branch complete today and merge back into master tonight (my time).
>> 
>> Going forward, do you still want to maintain and work off your clone, or would it be easier if I just gave you write access to the main project? Your contributions are so helpful and good, that there is little I am having to do other than just accept them :-)
>> 
>> For the watchdog reboot and occasional ram trashing, I too suspect the NET, NET_MSG or SMS code. It is the only place where things are externally controlled to result in variable length strings. I did review it a while ago, but didn't see anything obvious. The other possibility is sprintf() elsewhere in the code (such as STAT).
>> 
>> Running v2.1.1 in my car, I have seen the firmware version go bizarre about a month ago:
>> 
>> 2012-11-21 07:32:06.388834 -0500 info  main: #74 C EV915 rx msg F 2.1.1/V2,SFZRE8B15B3000569,1,1,TR2N,3(2G)
>> 2012-11-21 07:34:58.845568 -0500 info  main: #61 C EV915 rx msg F 49.51.51/V2,SFZRE8B15B3000569,1,1,TR2N,3(2G)
>> 
>> That is a sprintf().
>> 
>> Regards, Mark.
>> 
>> On 20 Dec, 2012, at 9:13 AM, Michael Balzer <dexter at expeedo.de> wrote:
>> 
>>> Mark,
>>> 
>>> I've rewritten all my sprintf() calls now. I introduced a new general string utils family to ease avoiding sprintf(), see my utils module addition.
>>> 
>>> I've had no garbled strings since and can now fetch all my history rows from the server, so it had some positive effect.
>>> 
>>> But the watchdog timeout reboots still occur, they still occasionally trash variables and I once still got the STKUNF flag from the reboot. That feels like some uninitialised pointer or writing beyond array / string bounds. I'm about to review the basic net code, if you've got an idea where to look first, tell me.
>>> 
>>> An example of the RAM trashing can still be seen on the server: MP-0 W17.4,8,17.4,8,17.4,8,17.4,8,-1
>>> When that occured, a lot of other data was displayed wrong as well.
>>> The TPMS vars never get written to by the twizy module. The values 17.4 & 8 mean both car_tpms arrays had been filled completely with 0x30 or '8'. Does that ring a bell?
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> 
>>> Am 18.12.2012 02:39, schrieb Mark Webb-Johnson:
>>>> 
>>>> In general, I try to minimise stack and ram usage on the small PICs.
>>>> 
>>>> Early on in OVMS, we had a bunch of local variables, and some were quite large. We were getting all sorts of random weird behavior (reboots, corrupt messages, etc). Since we changed to global variables, and very limited use of stacked function calls and local variables, things have been much better.
>>>> 
>>>> I agree that a large sprintf may be the cause of your problems. Can you try to change to itoa() and strcat(), to see if it makes an impact?
>>>> 
>>>> Regards, Mark.
>>>> 
>>>> On 18 Dec, 2012, at 8:05 AM, Michael Balzer wrote:
>>>> 
>>>>> Mark,
>>>>> 
>>>>> the client_app.pl hint was good, I had not recognized that as a server query utility yet.
>>>>> 
>>>>> I removed the comma (misread the draft) and can now see my H entries. However, that lead me back to my assumed connectivity issue:
>>>>> 
>>>>> MP-0 c31,0,2,6,RTPWR-BattCell,1,1,76,2012-12-17 23:18:43,2012-12-17 23:18:43
>>>>> MP-0 c31,0,3,6,RT-PWR-BattCell,14,16,1215,2012-12-17 23:13:11,2012-12-17 23:18:43
>>>>> MP-0 c31,0,4,6,RT-PWR-BattC�ll,1,1,65,2012-12-17 23:18:43,2012-12-17 23:18:43
>>>>> MP-0 c31,0,5,6,RT-PWR-BattPack,1,2,202,2012-12-17 23:13:11,2012-12-17 23:18:43
>>>>> MP-0 c31,0,6,6,RT-PWR-Usag,1,1,45,2012-12-17 23:13:11,2012-12-17 23:13:11
>>>>> 
>>>>> This C31 result shows all kinds of garbled chars in my module's messages, and even a truncation on "RT-PWR-UsageStats" (also missing parts on the data blob on that one).
>>>>> 
>>>>> Now that's a bit odd and most probably cannot be connected to a GPRS link failure -- as that would not garble single bytes in a TCP connection.
>>>>> 
>>>>> I could fix some similar output problems in DIAG mode more than once by reducing complex sprintf() calls, so I searched for C18 sprintf() stack usage and found nothing concrete, but many warnings about very high stack usage of the whole printf family, plus advice not to use them at all on small embedded systems. One source mentioned sprintf() will need 70+ bytes stack for a simple integer template.
>>>>> 
>>>>> I also have read a bit into the C18 software stack management and found my previous assumption to be correct: it's currently fixed to bank 12 (0xC00), so provides 256 bytes for any kind of parameter + local vars combination. I think sprintf() on a 256 byte stack could well be a source of problems... and stack overruns can produce weird effects, as those above. I think about rewriting all my sprintf calls to itoa/ltoa/ultoa, but find it strange they did no harm up to now, even with complex templates as in net_msgp_environment(). Or maybe they did, unrecognized?
>>>>> 
>>>>> Do you have some other info on C18 sprintf()? I'd rather avoid recoding every output without sprintf(), but that's my best bet currently...
>>>>> 
>>>>> Regards,
>>>>> Michael
>>>>> 
>>> 
>>> -- 
>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>> <dexter.vcf>_______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121220/09f1a410/attachment.htm>


More information about the OvmsDev mailing list